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/rspec/rspec-metagem 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 1y ago

• 20 active contributors
• Distributed ownership (top contributor 39% of recent commits)
• MIT licensed
• ⚠ Stale — last commit 1y ago
• ⚠ No CI workflows detected
• ⚠ 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 rspec/rspec-metagem repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/rspec/rspec-metagem.

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "rspec/rspec-metagem(\\.git)?\\b" \\
  && ok "origin remote is rspec/rspec-metagem" \\
  || miss "origin remote is not rspec/rspec-metagem (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 "lib/rspec.rb" \\
  && ok "lib/rspec.rb" \\
  || miss "missing critical file: lib/rspec.rb"
test -f "rspec.gemspec" \\
  && ok "rspec.gemspec" \\
  || miss "missing critical file: rspec.gemspec"
test -f "lib/rspec/version.rb" \\
  && ok "lib/rspec/version.rb" \\
  || miss "missing critical file: lib/rspec/version.rb"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "Gemfile" \\
  && ok "Gemfile" \\
  || miss "missing critical file: Gemfile"

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

rspec-metagem is a meta-gem that bundles rspec-core, rspec-expectations, and rspec-mocks into a single package, allowing users to install RSpec with one command while still enabling modular use of individual components. It solves the problem of dependency management by letting developers choose whether to use RSpec's full BDD stack or cherry-pick specific components (e.g., rspec-expectations in Test::Unit tests). Minimal meta-gem structure: lib/rspec.rb is the entry point that requires the three component gems (rspec-core, rspec-expectations, rspec-mocks); lib/rspec/version.rb defines the meta-gem version; rspec.gemspec declares the gem metadata and dependencies on the three components. The project is a thin wrapper with no business logic—it exists solely to coordinate dependency installation.

Ruby developers and QA engineers who want to write Behaviour-Driven Development (BDD) tests using RSpec's describe and it syntax, or who want to selectively use RSpec components (like assertions or mocks) within existing Test::Unit, Minitest, or other testing frameworks.

This is a mature, production-ready project: it's part of the RSpec ecosystem which has been widely adopted in Ruby since 2007. However, the README explicitly states this is the old meta-gem repository—the project has been superseded by the monorepo at rspec/rspec for new issues and releases, indicating this repository is in maintenance mode rather than active development.

Low risk for existing users, but migration risk for new users: this repository is no longer the primary development location. Relying on this for new work would be a mistake—contributions should go to rspec/rspec instead. The repository appears to have minimal commits and no visible CI/test configuration in the file list, suggesting limited active maintenance.

This repository is in maintenance mode. The README and SECURITY.md are present, suggesting basic governance, but there is no visible CI configuration (no .github/workflows files in the listing) and the project's active development has moved to the rspec/rspec monorepo. No specific recent changes or active PRs are evident from the file structure.

Clone the repository, install dependencies, and verify the meta-gem setup:

git clone https://github.com/rspec/rspec-metagem.git
cd rspec-metagem
bundle install
rake

Note: For new RSpec work, use https://github.com/rspec/rspec instead.

Daily commands: This is not a runnable application—it's a gem. Run tests with:

rake

Or install it into a Gemfile:

gem 'rspec'

Then use RSpec normally:

rspec --init
rspec

• lib/rspec.rb — Entry point that loads and coordinates the three core RSpec gems (rspec-core, rspec-expectations, rspec-mocks).
• rspec.gemspec — Defines the meta-gem's dependencies on rspec-core, rspec-expectations, and rspec-mocks; all contributors must understand the dependency contract.
• lib/rspec/version.rb — Maintains the version for the meta-gem; critical for release coordination across all three component gems.
• README.md — Explains the meta-gem architecture and the rationale for splitting RSpec into three independently-loadable components.
• Gemfile — Specifies development dependencies and ensures contributors have the correct test and build tools.

• Meta-gem package (Ruby, Bundler, RubyGems) — Declares dependency contract on the three core RSpec components; ensures all three are installed together
  • Failure mode: If dependency version constraints become too restrictive or incompatible, users cannot install any version of 'rspec'; if too loose, incompatible component versions may be mixed
• Entry point loader (lib/rspec.rb) (Ruby require mechanism) — Loads and initializes the three component gems when 'rspec' is required
  • Failure mode: If component gems are not installed or have changed their public API, require will fail or load only a subset of RSpec functionality
• Version coordinator (Ruby constants) — Maintains a single version constant used by rspec.gemspec to ensure consistent releases across the meta-gem
  • Failure mode: If version is not incremented correctly, releases may have mismatched versions or incorrect gem resolution

• User (bundle install or require 'rspec') → rspec.gemspec — RubyGems reads gemspec to determine meta-gem metadata and dependencies
• rspec.gemspec → rspec-core, rspec-expectations, rspec-mocks (as declared dependencies) — Gemspec declares which versions of the three components should be installed
• lib/rspec/version.rb → rspec.gemspec — Version constant is referenced by gemspec to stamp the meta-gem release version
• lib/rspec.rb (entry point) → rspec-core, rspec-expectations, rspec-mocks — Runtime: user require 'rspec' triggers sequential loading of the three component gems

Update the RSpec version for a new release

1. Edit the version constant in lib/rspec/version.rb to the new version number (lib/rspec/version.rb)
2. Verify rspec.gemspec references lib/rspec/version.rb and will pick up the new version (rspec.gemspec)
3. Run Rakefile build tasks to validate the gem specification (Rakefile)

Add a new development dependency

1. Add the gem to the Gemfile with appropriate version constraint (Gemfile)
2. Run bundle install to lock the dependency (Gemfile)

Update component gem dependencies

1. Edit the version constraints for rspec-core, rspec-expectations, or rspec-mocks in the dependencies section (rspec.gemspec)
2. Verify lib/rspec.rb will still correctly load the updated components (lib/rspec.rb)

• Ruby meta-gem pattern — Allows users to install individual RSpec components (rspec-core, rspec-expectations, rspec-mocks) separately while providing a convenient single 'rspec' gem for complete installations.
• Bundler & Gemspec — Standard Ruby packaging and dependency management; enables declarative specification of required component versions.
• Rake — Provides build automation and task orchestration for the meta-gem release and testing process.

• Meta-gem with external dependencies instead of monolithic single gem

  • Why: Allows granular adoption—users can use rspec-expectations with Test::Unit or rspec-core with alternative mocking libraries (mocha, rr, flexmock).
  • Consequence: Adds complexity: three separate gems must be kept in sync; users new to RSpec may need education on modular architecture.

• Central version constant in meta-gem instead of per-component versions

  • Why: Simplifies user expectations—'gem install rspec' installs compatible versions of all three components together.
  • Consequence: Release workflow must coordinate version bumps across three repositories; component versions are always in lockstep.

• Does not provide testing framework implementations—delegates to rspec-core, rspec-expectations, and rspec-mocks
• Does not handle assertion or mock functionality directly—purely a packaging/loading orchestrator
• Does not replace the monorepo structure described in the README (this is a legacy meta-gem; new work is in rspec/rspec monorepo)
• Does not provide IDE integrations, CI/CD plugins, or reporting formatters beyond what the component gems offer

• Avg cyclomatic complexity: ~1.5 — This is a minimal meta-gem; lib/rspec.rb contains only require statements, and version.rb is a constant. Very low cyclomatic complexity.
• Largest file: README.md (120 lines)
• Estimated quality issues: ~1 — Primary issue is implicit version synchronization between lib/rspec/version.rb and rspec.gemspec; no automated test validates they match. No code style or logic issues detected.

• Implicit version synchronization (Medium) — lib/rspec/version.rb + rspec.gemspec: Version is manually maintained in lib/rspec/version.rb and referenced by rspec.gemspec; no automated check ensures they stay in sync, risking version mismatches in releases.
• No explicit dependency pinning in loader (Low) — lib/rspec.rb: The entry point requires component gems without explicit version checks; if incompatible versions are installed, silent partial failures are possible.

• rspec.gemspec (Dependency coordination) — Central bottleneck for dependency declarations; any update to component gem versions or constraints must be coordinated here and will affect all users of the meta-gem.
• Release process (implicit across three repos) (Operational) — Releasing a new version of the meta-gem requires coordinating version bumps across rspec-core, rspec-expectations, and rspec-mocks, creating a serial bottleneck.

This repository is archived in practice—do not treat it as the primary RSpec repository. New issues, PRs, and releases go to rspec/rspec (the monorepo) instead. If you gem install rspec or update an existing RSpec dependency, you'll pull from this meta-gem, but all active development happens elsewhere. No hidden environment variables or service dependencies are apparent, but be aware that tests or builds here may not reflect the current RSpec state.

• Meta-gem (or umbrella gem) — This entire repository is a meta-gem—understanding this pattern is key to why rspec-metagem exists: it's a gem that depends on other gems and re-exports them, allowing single-command installation of a coordinated bundle while keeping components modular.
• Modular gem architecture — RSpec's design allows rspec-expectations to work in Test::Unit, or rspec-mocks in other frameworks, without forcing a monolithic stack—this meta-gem's whole purpose is to coordinate that modularity while providing convenience.
• Behaviour-Driven Development (BDD) — RSpec implements BDD philosophy (describe/it/expect syntax), which is the core value proposition this meta-gem delivers; understanding BDD helps explain why the component structure exists.
• Ruby require and Gemfile dependency resolution — This meta-gem's entire mechanism is declaring gem dependencies in rspec.gemspec and using require in lib/rspec.rb to load them; understanding Ruby's require system and bundler is essential to understanding how this thin wrapper works.

• rspec/rspec — The active monorepo where RSpec development now happens; this meta-gem repository is superseded by it.
• rspec/rspec-core — One of the three core gems bundled by this meta-gem; provides the describe/it syntax and test runner.
• rspec/rspec-expectations — One of the three core gems bundled by this meta-gem; provides the expect/matcher assertion syntax.
• rspec/rspec-mocks — One of the three core gems bundled by this meta-gem; provides double/mock/stub functionality.
• rspec/rspec-rails — Companion gem that integrates RSpec with Ruby on Rails, building on the core RSpec gems this meta-gem provides.

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 to validate metagem dependencies are in sync

This metagem depends on rspec-core, rspec-expectations, and rspec-mocks. There's no CI workflow to verify that the pinned versions in rspec.gemspec actually resolve correctly and that the umbrella gem properly exposes the expected API from its dependencies. This prevents regressions when dependency versions are updated.

• [ ] Create .github/workflows/dependency-sync.yml that runs bundle install and bundle exec rspec to verify the metagem works
• [ ] Add a test in the workflow that requires 'rspec' and verifies key classes from all three gems are available (e.g., RSpec::Core::ExampleGroup, RSpec::Matchers, RSpec::Mocks)
• [ ] Configure the workflow to run on push to main and on PRs that modify Gemfile or rspec.gemspec

Create comprehensive integration tests in lib/rspec_spec.rb validating metagem API surface

The repo lacks explicit tests verifying that requiring 'rspec' properly loads and exposes the full public API from all three component gems. This is critical for a metagem since its sole purpose is to aggregate and expose dependencies. Without these tests, breaking changes in downstream gems could go undetected.

• [ ] Create lib/rspec_spec.rb (or equivalent test file) that requires 'rspec' and validates core classes/modules are accessible: RSpec::Core, RSpec::Expectations, RSpec::Matchers, RSpec::Mocks
• [ ] Add assertions that key DSL methods work (e.g., describe, it, expect, allow, receive)
• [ ] Include tests for version constants to ensure lib/rspec/version.rb is properly exposed

Complete and publish SECURITY.md vulnerability reporting process

SECURITY.md exists but the README snippet indicates this is a deprecated metagem with the monorepo being the new home. However, SECURITY.md likely lacks clear guidance for reporting vulnerabilities specific to this gem. Given it's a widely-used metagem, having a clear, complete vulnerability disclosure policy is important for the community.

• [ ] Review SECURITY.md and verify it has a complete security contact email (likely security@rspec.info or similar)
• [ ] Add a statement directing users reporting metagem-specific issues to this repo vs. the monorepo vs. individual component repos
• [ ] Add explicit response time SLA and mention that urgent security fixes will be backported to this metagem even though new development happens in the monorepo

• Add GitHub Actions CI workflow (missing from .github/ directory) to auto-run tests on push and validate that the meta-gem correctly requires all three components.: Ensures this maintenance-mode repository doesn't silently break when upstream gems are updated.
• Expand README.md with a migration guide explaining why new users should use rspec/rspec monorepo instead, with specific steps for upgrading existing projects from this meta-gem.: Reduces confusion and redirects contributors to the active repository.
• Add a simple integration test in a test/ directory that loads rspec.rb and verifies that describe, it, expect, and allow are available, ensuring the meta-gem bundle remains functional.: Provides regression testing without duplicating the full RSpec test suites (those live in the component gems).

This is a meta-gem repository with a relatively clean security posture. No critical or high-severity vulnerabilities were detected. The main concerns are documentation gaps in the security policy, dependency audit visibility, and the deprecated status of the repository which could lead to users missing security updates. The presence of certificate files appears legitimate for gem signing purposes. Recommend enhancing SECURITY.md documentation and ensuring users are directed to the active monorepo for current maintenance and security patches.

• Low · Incomplete SECURITY.md Documentation — SECURITY.md. The SECURITY.md file provides security contact information through Tidelift, but lacks detailed information about supported versions, security update policies, and vulnerability disclosure timelines. This could delay security issue resolution. Fix: Expand SECURITY.md to include: supported versions, security update timeline, deprecated versions, CVE disclosure policy, and security patch release schedule.
• Low · Missing Dependency Pinning Information — Gemfile, rspec.gemspec. No Gemfile.lock file or dependency constraint information was provided for analysis. This makes it difficult to verify that locked dependencies are secure and reproducible across environments. Fix: Ensure Gemfile.lock is committed to version control and regularly audit dependencies using bundle audit or similar tools. Document minimum version requirements for critical dependencies.
• Low · Certificate Files Present Without Usage Context — certs/rspec.pem, certs/samphippen.asc. Certificate files (rspec.pem, samphippen.asc) are present in the repository. While this appears to be for gem signing, their presence warrants verification that private keys are not inadvertently committed. Fix: Verify these are public certificates only. Ensure private keys are never committed. Consider documenting the certificate rotation and signing process in SECURITY.md.
• Low · Repository Status Indication in README — README.md. README indicates 'This is the old rspec metagem repository' with direction to use a different monorepo. This could lead to security updates being missed if users continue using this outdated repository. Fix: Add a prominent deprecation notice at the top of README.md with clear migration instructions. Consider archiving this repository if it's no longer maintained.

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.