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/refinery/refinerycms 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 the board

• Last commit 2d ago
• 18 active contributors
• Distributed ownership (top contributor 45% of recent commits)
• MIT licensed
• CI configured
• Tests present

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

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "refinery/refinerycms(\\.git)?\\b" \\
  && ok "origin remote is refinery/refinerycms" \\
  || miss "origin remote is not refinery/refinerycms (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 "Gemfile" \\
  && ok "Gemfile" \\
  || miss "missing critical file: Gemfile"
test -f "config.ru" \\
  && ok "config.ru" \\
  || miss "missing critical file: config.ru"
test -f "core/app/assets/config/refinery_core_manifest.js" \\
  && ok "core/app/assets/config/refinery_core_manifest.js" \\
  || miss "missing critical file: core/app/assets/config/refinery_core_manifest.js"
test -f ".github/workflows/main.yml" \\
  && ok ".github/workflows/main.yml" \\
  || miss "missing critical file: .github/workflows/main.yml"
test -f "core/app/assets/javascripts/refinery/admin.js.erb" \\
  && ok "core/app/assets/javascripts/refinery/admin.js.erb" \\
  || miss "missing critical file: core/app/assets/javascripts/refinery/admin.js.erb"

# 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/refinery/refinerycms"
  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).

Refinery CMS is a Rails-based content management system that allows non-technical end users to manage website content without backend complexity. It supports Rails 6.1–8.1+ and Ruby 3.x–4.x, providing built-in admin interfaces for pages, images, and custom content types while remaining extensible via Rails engines and custom extensions. Monolithic gem structure: core/ directory contains the primary engine with app/ holding controllers, models, views, and assets (core/app/assets/images/refinery/ has 50+ PNG/GIF UI assets). Config at root level (Gemfile, config.ru), bin/ has Rails task runners, and documentation in doc/guides/ organized by feature category (1 - Getting Started, 7 - Hosting).

Rails developers building client-facing websites who need a CMS their non-technical clients can use to update pages, images, and content without learning Rails, and business users/content editors who need an intuitive admin interface to manage site content.

Production-ready with active maintenance: the repo shows CI pipelines for both legacy (.github/workflows/legacy.yml) and main branches, comprehensive test structure (bin/rspec in place), and documented support for recent Rails versions (6.1–8.1). The monolithic core/ structure and extensive asset library suggest years of refinement, though the README notes documentation is partially outdated and website is not currently live.

Moderate risk: single maintainer apparent (certs/parndt.pem suggests core author), potential ImageMagick security vulnerability explicitly called out in README (CVE-2016–3714), and dual-branch CI (legacy vs. main) suggests managing technical debt across multiple Rails version tiers. Upgrading Rails versions may require coordination across core, engine, and extension code.

Active Rails version support maintenance visible via main.yml and legacy.yml workflows; no specific PR or milestone data in provided file list, but .github/workflows structure suggests ongoing CI/testing for current Rails 6.1–8.1 compatibility. SECURITY.md presence indicates security issue response process is in place.

Clone and bundle: git clone https://github.com/refinery/refinerycms.git && cd refinerycms && bundle install. Then run tests with bin/rspec or start a dev server with bin/rails s (requires ImageMagick and PostgreSQL/SQLite3 configured).

Daily commands: bin/rails s starts the development server on default Rails port. Use bin/rspec to run the full test suite and bin/rake for Rake tasks. The Rakefile and config.ru provide Rails CLI integration.

• Gemfile — Declares all Ruby gem dependencies including Rails version support (6.1–8.1+) and core plugins; essential for understanding the project's dependency chain and compatibility boundaries.
• config.ru — Rack application entry point that initializes the Rails app; required to understand how the CMS boots and serves requests.
• core/app/assets/config/refinery_core_manifest.js — Asset pipeline manifest that bundles CSS/JS for the core CMS; critical for understanding frontend asset delivery in the admin and public-facing UI.
• .github/workflows/main.yml — Primary CI/CD pipeline that validates the codebase across Rails 6.1–8.1 and Ruby 3.x–4.x; shows what tests and checks all PRs must pass.
• core/app/assets/javascripts/refinery/admin.js.erb — Core admin interface JavaScript initialization; handles dynamic admin UI behavior, modal dialogs, and AJAX interactions that power the backend editor.
• Rakefile — Task definitions for build, test, and deployment; entry point for understanding the project's automation and release process.
• contributing.md — Development guidelines and contribution workflow; mandatory reading to align with project standards for submitting code.

Add a New Admin UI Component

1. Create JavaScript logic in a new file under core/app/assets/javascripts/refinery/ (core/app/assets/javascripts/refinery/my_feature.js)
2. Reference it in the admin manifest to load it in the asset pipeline (core/app/assets/config/refinery_core_manifest.js)
3. Add styles and icons to the images folder if needed (core/app/assets/images/refinery/icons/my_icon.png)
4. Initialize the component in the admin bootstrap script (core/app/assets/javascripts/refinery/admin.js.erb)

Add a New Gem Dependency

1. Add the gem to the Gemfile with appropriate version constraints and Rails version guards (Gemfile)
2. Run bundle install and commit Gemfile.lock (Gemfile)
3. Update CI workflow if the gem requires new setup or specific test configuration (.github/workflows/main.yml)

Add a New Rake Task

1. Define the task in the Rakefile or in a tasks file sourced from Rakefile (Rakefile)
2. Document the task usage and parameters in the task description (Rakefile)
3. Test the task locally and add it to CI if it needs to run on every build (.github/workflows/main.yml)

Contribute Code Changes

1. Read the contribution guidelines to understand branch naming and PR expectations (contributing.md)
2. Write tests using RSpec and run them locally with bin/rspec (.rspec)
3. Ensure CI passes in your PR; if it fails, review the workflow logs (.github/workflows/main.yml)

ImageMagick security policy must be configured post-install (CVE-2016–3714 called out in README—ignoring this leaves the CMS vulnerable). Rails version pinning in Gemfile is strict; upgrading to a new major Rails version may require code changes across core and extensions. Test suite requires both PostgreSQL and SQLite3 configured or will fail on migration tests. Admin routes and asset manifests are defined in core/app/assets/config; missing this breaks the admin interface. Development on macOS requires brew install imagemagick or the magick-installer gem.

• Rails Engines — Refinery is a Rails engine packaged as a gem; understanding engines is critical to extending Refinery and creating custom CMS features without modifying core code
• Asset Pipeline Manifests — core/app/assets/config/refinery_core_manifest.js controls which stylesheets, JavaScript, and images are compiled and served; critical for debugging missing admin UI styling or broken image references
• Polymorphic Associations — Refinery's content-type flexibility likely relies on polymorphic associations to allow a single admin interface to manage pages, images, and custom content types without hard-coded models
• ImageMagick Security Policies — Refinery uses ImageMagick for image resizing and optimization; CVE-2016–3714 is explicitly called out, requiring understanding of ImageMagick's policy configuration to prevent arbitrary code execution via image uploads
• Rails Request Routing and URL Generation — Refinery CMS's content tree structure (implied by pages and image management) likely uses custom routing to map user-friendly URLs (e.g., /about/team) to CMS content without explicit route definitions
• jQuery Plugin Architecture — The admin interface uses jQuery (mentioned in README); 68K of JavaScript in the repo likely includes custom jQuery plugins for drag-and-drop page reordering, image uploads, and inline editing
• Versioning and Gemspec Management — Supporting Rails 6.1–8.1 and Ruby 3.x–4.x requires careful gemspec constraints and version pinning; understanding how Refinery manages multiple Rails version branches (main.yml vs. legacy.yml CI) is essential for maintenance

• comfy/comfortable-mexican-sofa — Alternative Rails-based CMS with a focus on simplicity and extensibility; direct competitor solving the same client-facing content management problem
• dwl-app/dwl — Another Rails CMS offering; useful comparison for architectural decisions in admin UI and content modeling
• refinery/refinerycms-example-app — Official example/demo app for Refinery CMS showing how to deploy and extend the core CMS in a real Rails app
• palkan/rails_event_store — Event sourcing library often used alongside Rails CMS systems for audit logging and versioning of content changes
• rails/rails — The core Rails framework; Refinery is tightly coupled to Rails versions 6.1–8.1, so following Rails release cycle is essential

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 Ruby/Rails version matrix testing

The repo supports Rails 6.1 to 8.1+ and Ruby 3.x to 4.x, but the existing workflows (legacy.yml and main.yml) are not visible in the file structure. A comprehensive matrix test workflow should verify all supported combinations. This is critical for a CMS supporting multiple major versions to prevent breaking changes.

• [ ] Examine .github/workflows/main.yml and .github/workflows/legacy.yml to identify current test coverage gaps
• [ ] Create or extend a workflow file that tests against Rails 6.1, 7.0, 7.1, 8.0, 8.1 and Ruby 3.0, 3.1, 3.2, 3.3, 4.0
• [ ] Ensure the workflow runs RSpec tests via bin/rspec for each combination
• [ ] Add workflow status badge to README.md

Complete ImageMagick security documentation and add policy validation test

The README mentions CVE-2016–3714 vulnerability in ImageMagick with a warning about disabling features, but the guidance is truncated ('Mac OS X us'). This is a critical security concern for a CMS that handles image uploads. A PR should complete the security guide and add automated validation.

• [ ] Complete the truncated ImageMagick installation section in README.md with platform-specific policy instructions
• [ ] Create doc/guides/imagemagick-security.md with detailed setup instructions for different OS (Linux, macOS, Windows)
• [ ] Add a Rake task in Rakefile (e.g., rake security:check_imagemagick) to validate ImageMagick policy configuration
• [ ] Document the policy validation in SECURITY.md

Add comprehensive integration tests for core asset pipeline configuration

The repo has core/app/assets/config/refinery_core_manifest.js but no visible test file validating asset compilation and precompilation across Rails versions. Given the complexity of maintaining asset pipelines across Rails 6.1-8.1+, this is a high-risk area for regressions.

• [ ] Create spec/features/asset_pipeline_spec.rb to test asset manifest loading
• [ ] Add tests verifying that refinery_core_manifest.js correctly includes all assets in core/app/assets/images/refinery/
• [ ] Test asset fingerprinting and precompilation for both development and production environments
• [ ] Verify no missing image assets are referenced in core that would cause 404s in production

• Update and organize outdated documentation: the README notes docs are out of date; cross-reference doc/guides/ against the current codebase and add missing guides for Rails 8.1 and Ruby 4.x support.
• Add missing test coverage for core asset pipeline: core/app/assets/ directory has 50+ images but no visible test for asset compilation or manifest correctness in file list; write tests for core/app/assets/config/refinery_core_manifest.js.
• Create a modern deployment guide: README mentions Heroku (doc/guides/7 - Hosting/1 - Heroku.md) but no Docker, Kubernetes, or modern cloud platform guides visible; add containerization docs for Rails 8.1+ apps.

Refinery CMS has a moderate security posture with some notable concerns. The primary risk is the acknowledged ImageMagick vulnerability (CVE-2016-3714) which requires manual mitigation. The lack of visible dependency lock files and incomplete security documentation are secondary concerns. The project appears to be actively maintained based on CI/CD workflows, but security documentation needs enhancement. Strengths include a documented security reporting process and .gitignore configuration. Recommended immediate actions: (1) Verify all ImageMagick installations follow hardening guidelines, (2) Ensure dependency scanning is active in CI/CD, (

• High · ImageMagick CVE-2016-3714 (ImageTragick) Vulnerability — README.md, core/app/assets/images directory (image processing). The README explicitly warns about a critical ImageMagick security vulnerability (CVE-2016-3714). The application depends on ImageMagick for image processing but the documentation acknowledges that installations require manual policy configuration to disable dangerous features. This indicates potential exposure to remote code execution via malicious image files. Fix: 1) Document mandatory ImageMagick policy configuration in installation guides. 2) Consider implementing server-side image validation and sandboxing. 3) Evaluate alternative image processing libraries (e.g., libvips) that don't have this vulnerability class. 4) Implement strict file type validation for uploads.
• Medium · Missing Dependency Manifest — Gemfile (lock file not provided). No Gemfile.lock, package.json, or other dependency lock file is visible in the provided file structure. This makes it impossible to verify if known vulnerable versions of dependencies are being used. Rails CMS applications typically have many dependencies that could contain security vulnerabilities. Fix: 1) Ensure Gemfile.lock is committed to version control. 2) Regularly run 'bundle audit' to check for known vulnerabilities. 3) Implement automated dependency scanning in CI/CD pipeline (.github/workflows). 4) Keep all gems updated, especially Rails and authentication gems.
• Medium · Incomplete Security.md Documentation — SECURITY.md. The SECURITY.md file lacks important security policy details such as: supported versions receiving security updates, expected response timeframes, disclosure timeline, and whether a security.txt file exists. This makes it unclear how long users should expect to wait for patches or which versions are maintained. Fix: Enhance SECURITY.md with: 1) Explicit version support matrix (which Rails/Ruby versions receive updates). 2) Expected response and resolution timeframes. 3) Responsible disclosure guidelines. 4) Historical CVE/security advisory links. 5) Create /.well-known/security.txt as per RFC 9110.
• Medium · Certificate File in Repository — certs/parndt.pem. A certificate file (certs/parndt.pem) is present in the repository. While likely a public key, committing certificate files to version control can be problematic if private keys are accidentally committed or if the certificate management strategy is unclear. Fix: 1) Verify this is a public certificate only, not a private key. 2) Document the purpose and usage of this certificate. 3) Consider storing certificates in a certificate management system. 4) Add certificate expiration monitoring. 5) If ever a private key exists, add *.pem and certs/ to .gitignore immediately.
• Low · Outdated Documentation — README.md. README explicitly states 'some of our docs in this README are out of date, and our website is not currently live.' This creates security documentation gaps and may lead users to follow incorrect security practices based on deprecated information. Fix: 1) Prioritize updating all security-related documentation. 2) Implement a documentation versioning system aligned with release versions. 3) Add last-updated timestamps to security guides. 4) Create a documentation maintenance schedule in CONTRIBUTING.md.
• Low · Missing Content Security Policy Configuration — core/app/assets/ (no CSP configuration visible). No visible configuration for Content Security Policy (CSP) headers in the file structure. A Rails CMS application should implement CSP to prevent XSS attacks, particularly important given the asset management functionality. Fix: 1) Implement CSP headers in ApplicationController or middleware. 2) Use gems like secure_headers to manage CSP. 3) Configure restrictive policies for asset sources. 4) Test CSP with the CMS's asset pipeline and third-party integrations.

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.