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/danbooru/danbooru 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 2w ago
• 6 active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 81% of recent commits
• ⚠ Non-standard license (Other) — review terms

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

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

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other 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 "Gemfile" \\
  && ok "Gemfile" \\
  || miss "missing critical file: Gemfile"
test -f "Dockerfile" \\
  && ok "Dockerfile" \\
  || miss "missing critical file: Dockerfile"
test -f "app/components/application_component.rb" \\
  && ok "app/components/application_component.rb" \\
  || miss "missing critical file: app/components/application_component.rb"
test -f ".github/workflows/test.yaml" \\
  && ok ".github/workflows/test.yaml" \\
  || miss "missing critical file: .github/workflows/test.yaml"
test -f "app/components/README.md" \\
  && ok "app/components/README.md" \\
  || miss "missing critical file: app/components/README.md"

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

Danbooru is a self-hostable Rails-based image board with rich tagging, pooling, and content categorization. It's a fully-featured media management platform where users upload, tag, and organize images with hierarchical metadata, supporting millions of images with complex search and filtering capabilities. Classic Rails monolith: app/ contains components (app/components/ with ViewComponent pattern), models, controllers, and views organized by domain. Database layer via Rails ORM, frontend is HTML/SCSS/JavaScript with ViewComponent .erb templates (app/components/autocomplete_component/, etc.). Background jobs likely via Sidekiq or ActiveJob (inferred from Rails conventions). Docker containerization via Dockerfile and docker-compose for local dev.

Anime/art community administrators and contributors who need to run their own image sharing platform with granular tagging, moderation tools, and user management. Developers extending Rails applications with advanced metadata systems.

Production-ready and actively maintained. The repo shows 5.5M+ lines of Ruby code, comprehensive CI/CD via GitHub Actions (.github/workflows/), Docker support with docker-compose, and codecov integration. Recent activity and structured dependency management (.dependabot/config.yml) indicate ongoing development, not a legacy codebase.

Monolithic Rails app with significant operational dependencies: requires PostgreSQL, Redis, AWS SQS/S3 in production (per README Dependencies section), and multiple microservices for video processing and archival. Single points of failure include the database schema and the Rails monolith; breaking changes must be coordinated carefully. Dependency management is automated (Dependabot configured) but the large codebase means refactors carry integration risk.

Active development on dependency updates (Dependabot configured), test coverage expansion (codecov integrated), and containerization improvements (Docker workflows in .github/workflows/). The presence of .github/skills/ workflows suggests automated changelog and dependency management tooling is in use.

git clone https://github.com/danbooru/danbooru
cd danbooru
touch .env.local config/danbooru_local_config.rb
sudo docker compose up

Alternatively, use the automated setup: sh -c "$(curl -sSL https://raw.githubusercontent.com/danbooru/danbooru/master/bin/setup)" Danbooru will be available at http://localhost:3000.

Daily commands: After docker compose setup completes, Danbooru runs at http://localhost:3000. For development without Docker (not recommended per README): install Ruby (via .ruby-version), PostgreSQL, Redis, then bundle install && rails db:setup && rails s. Migrations: rails db:migrate. Tests: rails test (inferred from standard Rails setup and .github/workflows/test.yaml).

• Gemfile — Declares all Ruby dependencies for the Rails application; essential for understanding project requirements and reproducibility
• Dockerfile — Defines the containerized deployment environment; critical for understanding how the app runs in production
• app/components/application_component.rb — Base class for all ViewComponent instances; every UI component in the codebase extends this
• .github/workflows/test.yaml — CI/CD pipeline configuration; defines how code quality, tests, and deployments are automated
• app/components/README.md — Documents the component architecture pattern used throughout the UI layer
• .env — Environment configuration template; shows what settings are required to run the application
• README.md — Project overview, quickstart guide, and architectural philosophy for all new contributors

• Rails Router (Rails routing DSL) — Maps incoming HTTP requests to controller actions based on URL patterns
  • Failure mode: Misrouted requests return 404; malformed routes prevent app startup
• Controllers (Rails ActionController) — Business logic layer that fetches data from database and passes to views
  • Failure mode: N+1 queries, unoptimized database access, crashes if missing database records
• ViewComponents (ViewComponent gem) — Isolated, testable UI elements with encapsulated HTML, CSS, and JavaScript

Add a new UI component

1. Create a new component class inheriting from ApplicationComponent in app/components/ (app/components/my_new_component.rb)
2. Define the component's HTML template alongside the Ruby class (app/components/my_new_component/my_new_component.html.erb)
3. Add optional stylesheet for component-scoped styling (app/components/my_new_component/my_new_component.scss)
4. Add optional JavaScript for interactive behavior (app/components/my_new_component/my_new_component.js)
5. Use the component in your view templates with render MyNewComponent.new(prop: value)

Add a new deployment environment

1. Define environment-specific variables in .env or use existing template (.env)
2. Create a new GitHub Actions workflow file for deployment (.github/workflows/deploy-staging.yaml)
3. Update Dockerfile if environment needs different runtime dependencies (Dockerfile)
4. Add deployment secrets to GitHub repository settings and reference in workflow

Update Ruby dependencies

1. Add or update gem in Gemfile with version constraints (Gemfile)
2. Run bundle install to update Gemfile.lock (Gemfile.lock)
3. If adding system dependencies, update Dockerfile RUN commands (Dockerfile)
4. Run tests to ensure compatibility (.github/workflows/test.yaml)

Enforce new code style rules

1. Add or modify Ruby linting rules (.rubocop.yml)
2. Add or modify CSS linting rules (.stylelintrc.yml)
3. Run linters locally and fix violations (.github/workflows/test.yaml)
4. Update editor configuration if affecting formatting (.editorconfig)

• Ruby on Rails — Full-stack framework for rapid development of taggable content management system; built-in ORM, routing, and templating
• ViewComponent — Encapsulates reusable UI logic with single responsibility; enables testable, composable UI components
• Docker — Ensures consistent development, testing, and production environments across all contributors and deployment targets
• GitHub Actions — Native CI/CD integration with GitHub; automates testing, code quality checks, and deployments
• SCSS — Provides nested styling, variables, and mixins for maintainable component-scoped stylesheets

• Component-based UI with ViewComponent instead of separate frontend framework

  • Why: Keeps entire codebase in Rails ecosystem, reducing context switching and simplifying deployment
  • Consequence: Limited JavaScript interactivity without additional JS framework; requires inline JS in components

• GitHub Codespaces as primary development environment

  • Why: Removes local setup friction and makes onboarding immediate for new contributors
  • Consequence: Higher infrastructure costs; may mask environment-specific issues that only appear locally

• Single Dockerfile for all environments

  • Why: Simplifies build pipeline and ensures exact parity between development and production
  • Consequence: Larger image size; requires .dockerignore to exclude dev-only files

• Monolithic Rails app structure

  • Why: All features (posts, tags, comments, forums) in single codebase; simpler shared state and data relationships
  • Consequence: Increased complexity as app scales; harder to deploy individual features independently

• Real-time collaborative editing or live updates
• Mobile app (web-responsive UI only)
• Multi-tenant SaaS platform (single-instance deployment)
• GraphQL API (REST/JSON responses only based on Rails conventions)
• Machine learning-based content filtering or recommendations

Production requires AWS credentials (.env: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_S3_BUCKET) for media storage and SQS integration per README Dependencies section. Database superuser privileges needed for PostgreSQL setup. Redis is required for caching/sessions but not explicitly listed in docker-compose snippet provided—verify docker-compose.yml. The Ragel dependency (53K lines) suggests custom tokenization/parsing (likely for tag syntax); changing tag parsing is non-trivial. Rails 6+ requires Ruby >= 2.7; .ruby-version file pins the exact version—using a different version will fail silently. The archive service and video processing are external microservices not included; certain features won't work in dev without them. CRITICAL: .env.local and config/danbooru_local_config.rb are required but not in version control—dev setup must create them manually or the app won't boot.

• ViewComponent Pattern — Danbooru uses ViewComponent (Rails 6.1+ pattern) for all reusable UI in app/components/; understanding this is essential for frontend changes and avoiding template duplication
• Tag Hierarchies and Categorization — The categorized_tag_list_component and tag metadata suggest a sophisticated tag system with parent-child relationships and category buckets; core to Danbooru's content organization
• PostgreSQL Full-Text Search / Trigram Indexes — With millions of tags and posts, Danbooru likely uses PostgreSQL GiST/GIN indexes for efficient tag and post search; query performance depends on understanding this
• Rails Active Storage / Cloud Object Storage — Production uses AWS S3 for image storage (per README); understanding Rails Active Storage delegation is crucial for media upload/retrieval pipeline
• Background Job Queueing (Sidekiq/ActiveJob) — Pool/post versioning and media processing happen asynchronously via AWS SQS (mentioned in README); understanding Rails job patterns is essential for async features
• Docker Compose Multi-Service Orchestration — Local development requires coordinating PostgreSQL, Redis, and the Rails app via docker-compose.yml; understanding service dependencies and networking is essential for debugging
• Ragel State Machine Compilation — The 53K lines of Ragel suggest custom lexer/parser for tag query syntax; understanding how Ragel generates tokenizers explains tag search query parsing

• e621/e621-webserver — Another furry image board based on Danbooru codebase fork; closest alternative in the same ecosystem with similar tagging and pooling features
• dbooru/dbooru — Older Danbooru instance/fork; historical reference for tagging architecture design decisions
• lavafroth/iqdb-service — Reverse image search microservice commonly integrated with Danbooru instances for duplicate/similar post detection
• danbooru/danbooru-ansible — Companion deployment automation repo for setting up Danbooru on production servers using Ansible
• rails/rails — Core Rails framework; Danbooru is a Rails application and follows Rails conventions for models, views, controllers, and Active Record ORM

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 component-level tests for app/components/ directory

The repo has a well-structured ViewComponent library (app/components/) with 20+ components (autocomplete, blacklist, categorized_tag_list, comment, favorites_tooltip, etc.), but no visible test files in the file structure. ViewComponents should have unit tests for rendering logic, props validation, and edge cases. This would improve reliability and serve as documentation for component APIs.

• [ ] Create test/components/ directory mirroring app/components/ structure
• [ ] Add tests for app/components/autocomplete_component.rb testing rendering with different slot combinations
• [ ] Add tests for app/components/comment_component.rb testing vote/timestamp rendering logic
• [ ] Add tests for app/components/blacklist_component.rb testing filtering logic
• [ ] Integrate component tests into .github/workflows/test.yaml if not already present

Add stylelint configuration for SCSS consistency in components

The repo has .stylelintrc.yml at root level and multiple SCSS files in components (blacklist_component.scss, comment_component.scss, comment_votes_tooltip_component.scss, dtext_editor_component.scss, favorites_tooltip_component.scss), but no evidence of stylelint being enforced in CI. Adding stylelint to the test workflow would catch SCSS inconsistencies early and maintain component style quality.

• [ ] Verify .stylelintrc.yml configuration is appropriate for component SCSS patterns
• [ ] Add stylelint step to .github/workflows/test.yaml (or create dedicated workflow)
• [ ] Run stylelint against app/components/**/*.scss to identify any violations
• [ ] Document SCSS style guide expectations in app/components/README.md

Add Docker build caching and layer optimization documentation

The repo has Dockerfile and .github/workflows/docker-build.yaml but lacks documented best practices for Docker builds. Given the complexity of a Rails app with dev containers (.devcontainer/devcontainer.json), asset compilation, and dependency layers, contributors should have clear guidance on optimizing builds. This reduces build times and CI costs.

• [ ] Review current Dockerfile for multi-stage build opportunities and RUN instruction consolidation
• [ ] Document Dockerfile layer strategy in DOCKER.md or similar (referencing existing Dockerfile structure)
• [ ] Add build cache mount or buildkit configuration details to .github/workflows/docker-build.yaml comments
• [ ] Include examples of how to test Docker builds locally before pushing (docker build --progress=plain)

• Add component specs for app/components/autocomplete_component/ and app/components/blacklist_component/—these have .erb templates and .scss but no visible test files in the component directories: Low risk, isolated, improves test coverage for critical UI components without touching core business logic
• Document the Ragel tokenizer in AGENTS.md or CLAUDE.md (e.g., what syntax does it parse, where is the grammar file?)—the 53K Ragel lines suggest complex tag parsing that isn't documented: Helps future contributors understand non-obvious tag query syntax without reading the Ragel grammar file directly
• Add a troubleshooting section to README.md covering common Docker Compose failures (missing .env, PostgreSQL permission errors, Redis connection refused)—the current setup is terse: Reduces friction for new contributors; reuse content from CLAUDE.md/AGENTS.md if it exists

• High · Potential Hardcoded Secrets in .env File — .env. The presence of a .env file in the repository root suggests potential exposure of environment variables and secrets. If this file is tracked in version control, sensitive credentials (database passwords, API keys, encryption keys) could be exposed in the repository history. Fix: Ensure .env is listed in .gitignore and never committed. Use .env.example as a template. Rotate any secrets that may have been exposed. Implement secret management via environment variables in production.
• High · Missing CSRF Protection Configuration — app/components/* (various .html.erb files). Rails application with view components (ERB templates) that handle user input lacks explicit CSRF token validation evidence in the partial file structure provided. This is critical for form submissions. Fix: Verify all forms include Rails CSRF token helpers (form_with, form_for). Ensure protect_from_forgery is enabled in ApplicationController. Review form_component implementations for proper token inclusion.
• High · Potential XSS Vulnerability in Comment Components — app/components/comment_component/comment_component.html.erb, app/components/forum_post_component/forum_post_component.html.erb. Comment and forum post components (comment_component.html.erb, forum_post_component.html.erb) process user-generated content. Without proper escaping, malicious script injection is possible, especially given the user-taggable nature of the application. Fix: Ensure all user input is properly escaped using Rails helpers (h, sanitize, or safe_html). Use content_tag with block syntax. Review dtext_editor_component for proper output encoding. Implement Content Security Policy headers.
• High · Ruby Version Mismatch - Incomplete Dockerfile — Dockerfile. The Dockerfile shows incomplete ARG RUBY_VERSION="4.0.2" declaration (appears truncated with 'AR' at end). This incomplete configuration could lead to unexpected runtime behavior or security patches being missed. Fix: Complete and verify the Dockerfile syntax. Ensure Ruby version is consistently specified across .ruby-version, Gemfile, and Dockerfile. Pin to specific patch versions for reproducibility.
• Medium · Missing Security Headers Configuration — Application configuration (not visible in provided files). No visible security headers configuration (X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security) in the provided file structure. The application handles user-generated content and requires robust security headers. Fix: Configure security headers in config/initializers/security_headers.rb or via middleware. Use secure_headers gem. Set X-Frame-Options to DENY, X-Content-Type-Options to nosniff, and implement CSP.
• Medium · Potential SQL Injection in Tag/Search Components — app/components/categorized_tag_list_component/*, app/components/inline_tag_list_component/*. Rails application with tagging functionality (categorized_tag_list_component, inline_tag_list_component) suggests dynamic query building. Without visible parameterized query patterns, SQL injection risk exists. Fix: Always use parameterized queries with ActiveRecord. Never interpolate user input into SQL strings. Use ? or named placeholders exclusively. Audit all database queries in tag filtering logic.
• Medium · Docker Network Exposure — Dockerfile (comments/documentation). Dockerfile documentation shows --network host usage in examples, which exposes container network interfaces directly to the host. This is a security risk in production environments. Fix: Use custom Docker networks instead of host mode. Expose only necessary ports. Document production-appropriate networking. Use network policies and container-to-container communication.
• Medium · Dependency Management Not Fully Visible — Gemfile, Gemfile.lock. Gemfile is present but content not provided. Rails applications are vulnerable to known CVEs in gem dependencies. Dependabot configuration exists but specific vulnerabilities cannot be assessed without Gemfile.lock content. Fix: Run 'bundle audit' regularly. Review Dependabot alerts and apply patches promptly. Pin gem versions appropriately. Keep Rails and critical security gems updated. Review high-risk gems like those handling file uploads and authentication.
• Medium · — 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.