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/subhra74/xdm 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 — Stale — last commit 2y ago

• 6 active contributors
• GPL-2.0 licensed
• CI configured
• ⚠ Stale — last commit 2y ago
• ⚠ Single-maintainer risk — top contributor 95% of recent commits
• ⚠ GPL-2.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 subhra74/xdm repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/subhra74/xdm.

What it runs against: a local clone of subhra74/xdm — 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 subhra74/xdm | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 868 days ago | Catches sudden abandonment since generation |

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

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

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

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

XDM (Xtreme Download Manager) is a C# WPF desktop application that accelerates HTTP/HTTPS/FTP downloads by splitting files into parallel chunks, and extracts videos from streaming sites (MPEG-DASH, HLS, HDS). It integrates with Chrome, Firefox, Opera, and Chromium-based browsers via native messaging to intercept and manage downloads, with built-in video conversion to MP3/MP4. Monolithic WPF application structured as app/XDM/ containing core download engine, browser integration via native messaging, language packs in app/XDM/Lang/, FFmpeg tooling in app/XDM/FFmpegCustomBuild/, and MSIX packaging configuration in app/XDM/MsixPackaging/. MockServer (app/XDM/MockServer/) provides test infrastructure; no visible src/ or lib/ separation.

End-users on Windows/Linux/Mac who need faster downloads and video extraction from streaming sites; browser extension users who want centralized download management; contributors maintaining a multi-platform download utility with cross-browser integration.

Actively maintained and production-ready. The repo has a GitHub Actions CI/CD pipeline (.github/workflows/xdm-wpf-build.yml), structured language support across 20+ locales (app/XDM/Lang/), and an experimental beta version in circulation. Last activity appears recent with organized issue templates and discussions (GitHub discussions #768 referenced in README).

Single-maintainer risk under subhra74. The codebase is heavily C#-weighted (1.8MB) with significant JavaScript (browser integration, 197KB), but no visible test files in the top 60 structure—testing strategy is unclear. FFmpeg integration (app/XDM/FFmpegCustomBuild/) is a complex external dependency; custom build options suggest version-locking fragility. Native messaging host for Linux (app/XDM/LinuxNativeHost/xdm_messaging_host.py) suggests cross-platform complexity.

The project is transitioning to an experimental beta version (referenced in README as newer than master). Active discussion in GitHub discussions (#768) about the new version suggests major refactoring or feature development. CI pipeline is set up for WPF builds (.yml workflow), indicating ongoing integration work.

git clone https://github.com/subhra74/xdm.git
cd app/XDM
# Build using Visual Studio or: msbuild XDM.csproj /p:Configuration=Release

Note: README mentions Maven/Java in build instructions, but file structure is C# WPF—this is a documentation gap; use Visual Studio 2019+ or .NET SDK instead.

Daily commands: Open app/XDM/XDM.csproj in Visual Studio and press F5 (Debug) or use: ```bash msbuild app/XDM/XDM.csproj /p:Configuration=Debug /p:Platform=x64 bin/x64/Debug/XDM.exe

For browser integration testing, use app/XDM/MockServer/MockServer.csproj for test request handling.

• app/XDM/Lang/index.txt: Central language registry—defines which language packs are available and used by the localization system
• app/XDM/FFmpegCustomBuild/ffmpeg_options.txt: Configuration for video codec/format conversion; critical for video download feature, determines output quality and device compatibility
• app/XDM/LinuxNativeHost/xdm_messaging_host.py: Linux-side native messaging bridge between browsers and XDM; handles cross-platform integration for download interception
• .github/workflows/xdm-wpf-build.yml: CI/CD pipeline for automated WPF builds; defines how releases are compiled and tested
• app/XDM/MockServer/MockServer.cs: Test infrastructure for validating HTTP protocol handling and download logic without external servers
• app/XDM/MsixPackaging/: Windows Store packaging configuration; required for modern app distribution via Microsoft Store

Download logic: likely in core C# files (not visible in top 60, but search app/XDM/*.cs for chunk splitting). Browser integration: app/XDM/LinuxNativeHost/xdm_messaging_host.py for Linux; find Windows host executable in app/XDM/. Translations: add/edit app/XDM/Lang/LanguageName.txt files (index.txt shows structure). FFmpeg options: app/XDM/FFmpegCustomBuild/ffmpeg_options.txt controls video conversion profiles. Packaging: app/XDM/MsixPackaging/ for Store distribution.

No package.json or pom.xml in top 60: README mentions Maven/Java build but repo is C# WPF—the Java build docs are stale or for a legacy version. FFmpeg dependency is custom-built (app/XDM/FFmpegCustomBuild/ReadME.txt exists)—you cannot simply apt-get/brew install FFmpeg; must use bundled or pre-built binaries. Python host for Linux is separate from main WPF—Linux users run xdm_messaging_host.py as a daemon; native message port is hardcoded (check source). MSIX packaging requires Windows 10+; no clear guidance on legacy Windows support. Language files are plaintext (not JSON/XML)—custom parser likely in codebase, format undocumented.

• HTTP Range Requests & Parallel Chunking — XDM's core speed boost comes from splitting downloads into chunks via HTTP Range header and fetching them in parallel threads—understanding byte-range semantics and server compatibility is critical for debugging download failures
• Native Messaging (Browser Extension Protocol) — XDM bridges browsers and native app via native messaging; the Linux host (xdm_messaging_host.py) and Windows host use JSON-RPC over stdin/stdout to communicate download requests—essential for understanding cross-process integration
• Adaptive Bitrate Streaming (DASH, HLS, HDS) — XDM downloads from MPEG-DASH, Apple HLS, and Adobe HDS streams by reconstructing media from encrypted segment manifests—you must understand playlist parsing and segment reassembly to debug video extraction
• FFmpeg Encoding Pipeline & Codec Profiles — Video conversion to MP3/MP4 for 100+ devices relies on FFmpeg options (app/XDM/FFmpegCustomBuild/ffmpeg_options.txt)—mismatched codec parameters or missing audio passthrough cause silent/unplayable outputs
• MSIX App Packaging & Windows Store Distribution — app/XDM/MsixPackaging/ handles Store submission; MSIX manifest defines capabilities (network access, file access, URI schemes), and misconfigurations block browser integration
• Multi-threaded Download State Management — Parallel chunking requires thread-safe progress tracking, resume on disconnect, and atomic state updates; race conditions in chunk completion or file assembly corrupt downloads
• URI Scheme Registration & Browser Deep-Linking — XDM registers custom URI schemes (xdm:// or similar) to intercept download links from browsers; scheme routing and permission scoping prevent security holes and failed interception

• aria2/aria2 — Command-line multi-protocol download accelerator with chunking; shares core acceleration philosophy but no UI/video support
• yt-dlp/yt-dlp — Video extraction from 1000+ streaming sites; complementary tool XDM could integrate or replace for video downloads
• MrS0m30n3/youtube-dl-gui — GUI wrapper around youtube-dl showing browser integration patterns for video download tools
• electron-userland/electron-builder — Cross-platform packaging framework; XDM uses MSIX (Windows) but could adopt Electron for unified Mac/Linux builds
• mozilla/webextensions-examples — Native messaging bridge examples for Firefox/Chrome integration; XDM's browser-to-app communication pattern relies on this protocol

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 GitHub Actions workflow for WPF build validation on pull requests

The repo has a WPF build workflow file (.github/workflows/xdm-wpf-build.yml) but it likely only runs on specific events. New contributors should add validation that runs on every PR to catch build failures early. This is critical for a C# WPF desktop application where build integrity directly affects user experience.

• [ ] Review existing .github/workflows/xdm-wpf-build.yml configuration
• [ ] Add PR trigger event to run on pull_request events (branches: master, develop)
• [ ] Add status check requirements in branch protection rules documentation
• [ ] Test workflow by creating a test PR with intentional build failure

Create language file validation workflow and linter

The app/XDM/Lang directory contains 25+ language translation files (Arabic, Chinese, French, German, etc.) with no apparent validation. A contributor could create a CI workflow to validate translation files for consistency: checking for missing keys, encoding issues, and formatting. This prevents broken translations from reaching users.

• [ ] Analyze app/XDM/Lang/English.txt and app/XDM/Lang/index.txt to understand key format
• [ ] Create a Python/C# script to validate all .txt files have matching keys
• [ ] Add GitHub Actions workflow (.github/workflows/lang-validation.yml) to run linter on every PR
• [ ] Document expected language file format in a new app/XDM/Lang/README.md

Add unit tests for MockServer component used in testing

The app/XDM/MockServer directory contains RequestHandler.cs and MockServer.cs but has no accompanying test files. Adding unit tests for this testing utility improves code reliability and serves as documentation for how download scenarios should be tested. This is essential infrastructure for testing a download manager.

• [ ] Create app/XDM/MockServer.Tests project following C# testing conventions
• [ ] Add tests for MockServer.cs covering request handling, response generation, and edge cases
• [ ] Add tests for RequestHandler.cs covering various HTTP request scenarios
• [ ] Update .github/workflows/xdm-wpf-build.yml to run MockServer tests in CI pipeline

• Add unit tests for MockServer request handlers (app/XDM/MockServer/RequestHandler.cs)—currently no .Tests project visible; start with HTTP header parsing and chunk range validation.
• Standardize and document FFmpeg options schema (app/XDM/FFmpegCustomBuild/ffmpeg_options.txt)—currently unstructured; create a JSON schema and validation helper to prevent invalid codec combinations.
• Update stale build documentation in README (mentions Maven/Java)—add C# WPF build prerequisites, Visual Studio version requirements, and .NET SDK version constraints; include Linux native host setup steps.

The codebase shows moderate security maturity but has notable gaps. Primary concerns include: (1) Absence of visible dependency manifests preventing vulnerability assessment, (2) Native messaging implementation that requires careful security review, (3) Mock/test servers mixed with production code, and (4) Multiple language file sources needing content validation. The multi-platform nature (WPF/C#, Python, JavaScript) increases the attack surface. Strong recommendations: establish complete dependency tracking with automated scanning, segregate test code, conduct security code review of native APIs, and implement secure internationalization practices. No evidence of hardcoded secrets or obvious injection vulnerabilities was found in the file structure analysis.

• Medium · Native Host Script Exposed — app/XDM/LinuxNativeHost/xdm_messaging_host.py. The Linux native host messaging script (xdm_messaging_host.py) is present in the repository. Native messaging hosts can be attack vectors if not properly secured. The script should be reviewed for input validation, privilege escalation risks, and secure inter-process communication patterns. Fix: Review the script for secure input handling, validate all messages from the browser extension, implement proper error handling, and ensure it runs with minimal privileges. Consider sandboxing the native host process.
• Medium · Mock Server in Production Codebase — app/XDM/MockServer/. A MockServer implementation is included in the main codebase (MockServer.cs, RequestHandler.cs). Mock servers should not be deployed to production as they may bypass security controls and authentication mechanisms intended for real backends. Fix: Segregate mock/test code from production builds. Use build configuration flags to exclude MockServer from production releases. Consider moving to a separate test directory or repository branch.
• Medium · Missing Dependency Information — Project root and subdirectories. No package dependency files (package.json, requirements.txt, .csproj with package references, pom.xml, etc.) were provided in the analysis. This makes it impossible to assess for known vulnerable dependencies. The project appears to be a multi-language application (C#, Python, JavaScript) with no visible dependency management details. Fix: Provide complete dependency manifests for all languages used. Implement automated dependency scanning using tools like OWASP Dependency-Check, Snyk, or GitHub's Dependabot. Maintain an up-to-date Software Bill of Materials (SBOM).
• Low · Multiple Language Files Without Content Validation — app/XDM/Lang/*.txt. The application includes 30+ language files (Arabic, Chinese, Persian, etc.). Without seeing the content, there's a potential risk of localization-based injection attacks if these files are parsed unsafely or used in concatenation contexts without sanitization. Fix: Ensure all language file parsing uses secure deserialization methods. Validate and sanitize all content from language files before rendering in UI. Avoid using eval() or unsafe string concatenation with localization data.
• Low · FFmpeg Custom Build Configuration Exposed — app/XDM/FFmpegCustomBuild/ffmpeg_options.txt. Custom FFmpeg build options are stored in ffmpeg_options.txt. While not necessarily a vulnerability, this could reveal information about custom compilation flags or security-relevant settings. Fix: Review the FFmpeg configuration to ensure no insecure options are enabled. Document the rationale for any custom flags. Consider moving sensitive build configurations to CI/CD secrets rather than source control.

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.