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/RipMeApp/ripme 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 7mo ago
• 12 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 7mo ago
• ⚠ Single-maintainer risk — top contributor 86% of 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 RipMeApp/ripme repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/RipMeApp/ripme.

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

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT 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 "src/main/java/com/rarchives/ripme/App.java" \\
  && ok "src/main/java/com/rarchives/ripme/App.java" \\
  || miss "missing critical file: src/main/java/com/rarchives/ripme/App.java"
test -f "src/main/java/com/rarchives/ripme/ripper/AbstractRipper.java" \\
  && ok "src/main/java/com/rarchives/ripme/ripper/AbstractRipper.java" \\
  || miss "missing critical file: src/main/java/com/rarchives/ripme/ripper/AbstractRipper.java"
test -f "src/main/java/com/rarchives/ripme/ripper/DownloadThreadPool.java" \\
  && ok "src/main/java/com/rarchives/ripme/ripper/DownloadThreadPool.java" \\
  || miss "missing critical file: src/main/java/com/rarchives/ripme/ripper/DownloadThreadPool.java"
test -f "src/main/java/com/rarchives/ripme/ripper/AbstractHTMLRipper.java" \\
  && ok "src/main/java/com/rarchives/ripme/ripper/AbstractHTMLRipper.java" \\
  || miss "missing critical file: src/main/java/com/rarchives/ripme/ripper/AbstractHTMLRipper.java"
test -f "build.gradle.kts" \\
  && ok "build.gradle.kts" \\
  || miss "missing critical file: build.gradle.kts"

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

RipMe is a cross-platform Java desktop application that downloads entire albums/galleries from 100+ websites (DeviantArt, Danbooru, EHentai, ArtStation, etc.) for archival purposes. It provides a GUI and CLI interface that automates fetching, organizing, and bulk-downloading media from sites that don't offer native export tools, using site-specific HTML/JSON parsers wrapped in a unified ripper framework. Monolithic single-module Gradle build (build.gradle.kts). Core framework: AbstractRipper base class in src/main/java/com/rarchives/ripme/ripper/ with subclasses (AbstractHTMLRipper, AbstractJSONRipper, AbstractSingleFileRipper, VideoRipper). 100+ concrete rippers in src/main/java/com/rarchives/ripme/ripper/rippers/ (AllporncomicRipper.java, ArtStationRipper.java, etc.). App.java is entry point. Downloader threading via DownloadThreadPool, DownloadFileThread, DownloadVideoThread.

Digital archivists, content preservation enthusiasts, and platform-agnostic media collectors who need to bulk-download galleries from art/image-sharing sites without relying on web scrapers they build themselves. Contributors are volunteer maintainers maintaining 100+ site-specific rippers.

Actively maintained but small team. Java 17+ requirement (set in Java 21 ecosystem), GitHub Actions CI/CD configured (gradle.yml), coverage tracking via Coveralls. Two active maintainers as of 2025 (@MetaPrime, @soloturn), with development consolidation happening from ripmeapp2/ripme fork. Production-ready for defined use cases, actively developed with recent repo consolidation.

Heavy dependency on site-specific HTML/JSON parsing (100+ rippers = high fragility to site layout changes). Single-maintainer risk partially mitigated by two active maintainers, but sparse commit velocity visible. Java 17 minimum may limit user base on older systems. No explicit test coverage visible in file structure (no src/test/ mentioned), creating regression risk when site-specific rippers are modified.

Recent activity: repo consolidation from ripmeapp2/ripme back to ripmeapp/ripme (mentioned in README), Java 17+ modernization, maintainer restructuring with @MetaPrime returning. No specific open PRs/issues listed in provided data, but stale issues acknowledged on both repos from period of inactivity.

git clone https://github.com/RipMeApp/ripme.git && cd ripme && ./gradlew build && java -jar build/libs/ripme.jar (or ./build.sh on Linux/Mac, build.bat on Windows). Requires Java 17+.

Daily commands: Desktop GUI: java -jar ripme.jar (after build). CLI: java -com.rarchives.ripme.App [URL] [output-dir] (inferred from App.java entry point). Dev/build: ./gradlew build (Linux/Mac) or gradlew.bat build (Windows).

• src/main/java/com/rarchives/ripme/App.java — Main entry point for the RipMe application; all contributors must understand the initialization flow and architecture
• src/main/java/com/rarchives/ripme/ripper/AbstractRipper.java — Core base class for all ripper implementations; defines the contract and lifecycle that every site-specific ripper must follow
• src/main/java/com/rarchives/ripme/ripper/DownloadThreadPool.java — Manages concurrent downloads and thread lifecycle; critical for understanding performance and resource management
• src/main/java/com/rarchives/ripme/ripper/AbstractHTMLRipper.java — Specialization of AbstractRipper for HTML-based content; template for most site-specific rippers in the codebase
• build.gradle.kts — Build configuration and dependency declaration; essential for setting up the development environment and understanding external libraries
• README.md — Project overview, purpose, and usage instructions; every contributor should understand the mission and requirements

Add a New HTML-Based Site Ripper

1. Create a new class in src/main/java/com/rarchives/ripme/ripper/rippers/ that extends AbstractHTMLRipper (src/main/java/com/rarchives/ripme/ripper/rippers/YourSiteRipper.java)
2. Implement getHost() to return the domain, getGID() to extract the album/content ID from URL (src/main/java/com/rarchives/ripme/ripper/rippers/YourSiteRipper.java)
3. Override fetchDocument() or parseDocument() to extract image/media URLs from HTML using JSoup or regex (src/main/java/com/rarchives/ripme/ripper/rippers/YourSiteRipper.java)
4. Call addURLToDownload() for each extracted media URL with appropriate filename (src/main/java/com/rarchives/ripme/ripper/rippers/YourSiteRipper.java)
5. Register your ripper in the factory or auto-discovery mechanism (likely in App.java or a ripper registry) (src/main/java/com/rarchives/ripme/App.java)

Add a New JSON API-Based Site Ripper

1. Create a new class in src/main/java/com/rarchives/ripme/ripper/rippers/ that extends AbstractJSONRipper (src/main/java/com/rarchives/ripme/ripper/rippers/YourAPIRipper.java)
2. Implement getHost() for domain matching and getGID() to extract the album/profile ID (src/main/java/com/rarchives/ripme/ripper/rippers/YourAPIRipper.java)
3. Override getAPIURL() to construct the API endpoint(s) and parseJSON() to extract media URLs from JSON response (src/main/java/com/rarchives/ripme/ripper/rippers/YourAPIRipper.java)
4. Call addURLToDownload() for each media item, handling pagination if needed (src/main/java/com/rarchives/ripme/ripper/rippers/YourAPIRipper.java)

Extend Download Behavior or Threading

1. Review DownloadThreadPool.java to understand the thread pool architecture and queue management (src/main/java/com/rarchives/ripme/ripper/DownloadThreadPool.java)
2. Modify DownloadFileThread.java or DownloadVideoThread.java to customize retry logic, headers, or post-processing (src/main/java/com/rarchives/ripme/ripper/DownloadFileThread.java)
3. Update AbstractRipper.java if you need to change how URLs are queued or how completion is tracked (src/main/java/com/rarchives/ripme/ripper/AbstractRipper.java)

• Java 17+ — Cross-platform desktop application; runs on Windows, Linux, and macOS without recompilation; mature ecosystem for HTTP clients and threading
• Gradle (Kotlin DSL) — Modern build tool with strong dependency management; Kotlin DSL provides cleaner, more maintainable build configuration than XML
• JSoup / Regex — HTML parsing and content extraction; JSoup provides CSS selector support for robust DOM navigation; regex for simpler patterns
• ThreadPoolExecutor — Efficient concurrent downloads; bounded thread pool prevents resource exhaustion on large albums; allows user control over parallelism

• Single-threaded per-site parsing, multi-threaded download phase

  • Why: Sites may have rate-limiting or bot detection; sequential parsing respects crawl delays while parallel downloads maximize throughput once URLs are known
  • Consequence: Initial discovery is slower, but bulk transfer is optimized; requires two-phase architecture

• Site-specific rippers over universal scraper

  • Why: Each site has unique HTML structure, API endpoints, and anti-bot measures; universal scraper would be fragile and unmaintainable across 100+ sites
  • Consequence: Codebase is large (345 files) but modular; adding a new site requires a new ripper class but does not affect others

• Desktop application instead of web service

  • Why: Users retain full control over downloads and can run locally; avoids server costs and legal liability; respects user privacy
  • Consequence: Users must install Java and manage their own bandwidth/storage; no centralized monitoring or analytics

• Does not authenticate with user accounts on target sites (some sites may require login; this is user's responsibility)
• Does not handle encrypted or DRM-protected content
• Not a streaming service; download-only model for archival
• Does not provide real-time synchronization or cloud storage integration
• Not web-based; desktop-only application

No explicit test suite visible (no src/test/ directory listed) — test coverage is opaque; changes to rippers risk silent breakage. Site-specific parsing is fragile: Rippers hardcode selectors/API endpoints; any site layout change requires immediate maintenance or that ripper breaks. Java 17 minimum may require user Java environment upgrades; no fallback for older JVMs. Threading defaults: DownloadThreadPool concurrency settings not visible; may cause rate-limiting issues on strict sites if not tuned. No explicit rate-limiting visible in provided files — risk of IP bans if downloading too aggressively. ripme.json config file referenced but structure/schema not explained in provided README.

• Abstract Factory + Template Method Pattern — RipMe uses AbstractRipper as template (common download workflow) and per-site subclasses as concrete factories (site-specific parsing); understanding this dual pattern is essential for adding new rippers without duplicating code
• HTML Selector-Based Web Scraping (CSS/XPath) — AbstractHTMLRipper relies on Jsoup to extract media URLs via DOM selectors; any new HTML-based ripper requires understanding how to reverse-engineer site structure and write fragile-but-necessary selectors
• Pagination and Lazy-Loading Traversal — Many rippers must walk through multi-page galleries or infinite-scroll APIs; AbstractHTMLRipper and AbstractJSONRipper both implement pagination loops that need to handle rate limits and dynamic URLs
• Thread Pool Pattern with Work Queue — DownloadThreadPool manages concurrent file/video downloads with bounded parallelism to avoid overwhelming target servers and user bandwidth; critical for understanding why downloads stall or fail
• User-Agent Rotation and Header Spoofing — Many sites block aggressive scrapers; rippers likely need to rotate User-Agent headers and mimic browser behavior to avoid 403/429 responses; this pattern is implicit in most site-specific rippers
• Transient vs. Permanent Network Failures — DownloadFileThread must distinguish between recoverable errors (retry) and fatal ones (skip); no explicit backoff visible in provided files, suggesting this is a maturity gap
• Serialization for State Persistence (ripme.json) — ripme.json config file is referenced but not explained; likely stores user settings, download history, or ripper state; understanding its schema is needed for feature additions

• ytdl-org/youtube-dl — Alternative bulk downloader for video-hosting sites; shares architectural pattern of site-specific extractors with fallback handlers
• yt-dlp/yt-dlp — Modern fork of youtube-dl with active maintenance; similar multi-site downloader approach applicable to ripme's 100+ rippers
• soimort/you-get — Cross-platform media downloader for 100+ sites; comparable architecture of site-specific handlers and concurrent download management
• RipMeApp/ripme2 — Historical fork (ripmeapp2/ripme) where development continued during ripmeapp/ripme inactivity; being consolidated back into main repo
• ripmeapp/ripme-themes — Companion repo for GUI themes/skins used by RipMe's desktop interface (if it exists)

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 AbstractRipper and core ripper implementations

The repo has 50+ ripper implementations (DanbooruRipper, DeviantartRipper, FlickrRipper, etc.) but no visible test directory in src/test. Core classes like AbstractHTMLRipper.java, AbstractJSONRipper.java, and AbstractRipper.java lack unit test coverage. This is critical for a download tool where edge cases (malformed HTML, network errors, invalid JSON) could cause data loss or crashes.

• [ ] Create src/test/java/com/rarchives/ripme/ripper directory structure
• [ ] Add unit tests for AbstractRipper.java testing core download logic, error handling, and thread pool management
• [ ] Add unit tests for AbstractHTMLRipper.java testing HTML parsing and image URL extraction
• [ ] Add unit tests for AbstractJSONRipper.java testing JSON parsing edge cases
• [ ] Configure Gradle to run tests in gradle.yml CI workflow

Extract common ripper patterns into shared utility methods

With 50+ ripper implementations (AllporncomicRipper, ArtStationRipper, BaraagRipper, BooruRipper, etc.), there's significant code duplication for common tasks like URL validation, filename sanitization, and pagination. Creating shared utility classes would reduce maintenance burden, improve consistency, and make adding new rippers faster.

• [ ] Create src/main/java/com/rarchives/ripme/utils/RipperUtils.java with common methods for URL normalization, filename sanitization, and delay handling
• [ ] Create src/main/java/com/rarchives/ripme/utils/HTMLParsingUtils.java for shared HTML extraction patterns used across multiple rippers
• [ ] Refactor 5-10 existing rippers (e.g., DanbooruRipper, FlickrRipper, DeviantartRipper) to use new utilities
• [ ] Add unit tests for utility methods in src/test/java/com/rarchives/ripme/utils/
• [ ] Document patterns in CONTRIBUTING.md with examples

Add integration tests for top 10 rippers in GitHub Actions workflow

The gradle.yml CI workflow exists but likely only runs compilation. With 50+ rippers supporting different sites, regressions are easy to miss. Adding integration tests for the most popular rippers (Danbooru, DeviantArt, Flickr, E621, etc.) would catch broken scrapers before release and validate that site structure changes don't silently break downloads.

• [ ] Create src/test/java/com/rarchives/ripme/ripper/rippers/integration/ directory for integration tests
• [ ] Add integration test class for DanbooruRipper testing against a real endpoint or mock server
• [ ] Add integration test class for DeviantartRipper with sample gallery URLs
• [ ] Add integration test class for FlickrRipper testing pagination and metadata extraction
• [ ] Update .github/workflows/gradle.yml to run integration tests with timeout protection and network skip option
• [ ] Document how to run integration tests locally in CONTRIBUTING.md

• Add unit tests for AbstractHTMLRipper and AbstractJSONRipper base classes (src/test/java/com/rarchives/ripme/ripper/) to establish regression detection before adding new rippers, since no test directory exists yet
• Document the ripper authoring checklist: create a RIPPER_TEMPLATE.java and RIPPER_DEVELOPMENT.md in root explaining mandatory methods, URL pattern registration, and testing flow for contributors adding new sites
• Add graceful retry logic with exponential backoff to DownloadFileThread.java and DownloadVideoThread.java to handle transient network failures, reducing user frustration on slow/flaky connections

• High · Insecure Vulnerability Reporting Channel — SECURITY.md. The SECURITY.md file directs users to report vulnerabilities via public GitHub issues or Reddit, which are not secure channels for sensitive security disclosures. This could expose vulnerability details before patches are available. Fix: Implement a responsible disclosure policy using GitHub's private security advisory feature or a dedicated security@project email address. Use coordinated disclosure timelines.
• High · Missing Dependency Information — build.gradle.kts / dependencies section. No dependency file content (build.gradle.kts, pom.xml, etc.) was provided for analysis. This prevents assessment of known vulnerable library versions, supply chain risks, and transitive dependencies that could affect security. Fix: Provide complete dependency manifest. Implement dependency scanning tools like OWASP Dependency-Check, Snyk, or Gradle's dependency vulnerability scanning in CI/CD pipeline.
• High · Large Attack Surface - Multiple Ripper Implementations — src/main/java/com/rarchives/ripme/ripper/rippers/. The codebase contains 80+ ripper implementations for different websites. Each ripper likely performs web scraping with custom HTML/JSON parsing logic, creating multiple potential injection vectors (XSS, XXE, Path Traversal) if not properly sanitized. Fix: Implement centralized input validation and sanitization. Use established HTML parsing libraries (jsoup with safe mode). Validate all URL inputs. Implement XXE protection when parsing XML/JSON responses.
• Medium · Unsafe File Download Operations — src/main/java/com/rarchives/ripme/ripper/DownloadFileThread.java, DownloadVideoThread.java. DownloadFileThread.java and DownloadVideoThread.java likely perform file downloads from untrusted sources. Without proper validation, this could lead to Path Traversal attacks, overwriting system files, or downloading malicious content. Fix: Validate all file paths against a whitelist directory. Use Path.normalize() and ensure files are within intended download directory. Implement file size limits. Verify file signatures/hashes when possible.
• Medium · Potential Insecure Deserialization — ripme.json / configuration loading. The application handles configuration via ripme.json and likely deserializes user-controlled data. Java deserialization of untrusted data can lead to RCE attacks if vulnerable gadget chains are available. Fix: Avoid Java's native serialization for untrusted input. Use JSON parsing libraries (Jackson, Gson) with strict type binding. Implement input validation on all deserialized objects. Consider signing configuration files.
• Medium · No Visible HTTPS/TLS Enforcement — src/main/java/com/rarchives/ripme/ripper/ (HTTP client configuration). As a bulk downloader application, HTTPS enforcement for all remote connections is critical but not visible in the provided codebase. HTTP connections could expose data and be subject to MITM attacks. Fix: Enforce HTTPS for all remote connections. Implement certificate pinning for critical domains. Disable HTTP support. Use TLSv1.2 minimum. Validate SSL certificates properly.
• Medium · Limited Security in Security Policy — SECURITY.md. Only version 2.1.x is supported with security updates. Older versions receive no patches, and the end-of-life policy is not clearly defined, potentially leaving users on outdated versions vulnerable. Fix: Define clear version support lifecycle. Provide regular security updates for at least 1-2 prior major versions. Implement auto-update mechanism or strong deprecation warnings.
• Low · No Code Signing for Releases — README.md, Release distribution. The README references downloading ripme.jar from releases, but no mention of code signing or checksum verification is provided. Users cannot verify the integrity of downloaded binaries. Fix: Sign all releases with GPG. Provide SHA-256 checksums and GPG signatures. Document verification process for users. Consider using GitHub's release attestations.
• Low · No SECURITY.txt Standard — undefined. The project doesn't implement RFC 9110 .well-known/security.txt standard 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.