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/public-activity/public_activity 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 4mo ago
• 15 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 4mo ago
• ⚠ Concentrated ownership — top contributor handles 60% 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 public-activity/public_activity repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/public-activity/public_activity.

What it runs against: a local clone of public-activity/public_activity — 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 public-activity/public_activity | 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 | Last commit ≤ 147 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "public-activity/public_activity(\\.git)?\\b" \\
  && ok "origin remote is public-activity/public_activity" \\
  || miss "origin remote is not public-activity/public_activity (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"

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

PublicActivity is a Rails gem that automatically tracks model changes (create, update, destroy) and stores them as Activity records, enabling GitHub-style activity feeds. It supports ActiveRecord, Mongoid, and MongoMapper, storing what changed and who made the change with customizable actions and view rendering. Modular ORM abstraction: lib/public_activity/orm/ contains pluggable implementations for ActiveRecord, Mongoid, and MongoMapper (each with activist.rb, activity.rb, adapter.rb, trackable.rb). Core logic in lib/public_activity/ (common.rb, config.rb, actions/ for CRUD tracking). Generators in lib/generators/ scaffold migrations and schema upgrades.

Rails developers building activity feeds, audit trails, or user notification systems who need automatic model change tracking without writing custom callbacks. Particularly useful for teams building social features or compliance-focused applications.

Production-ready and actively maintained. The gem supports Rails 6.1+ and Ruby 3.0+ (v3.0+), with clear CI via GitHub Actions (.github/workflows/main.yml), multiple gemfile appraisals for version testing, and a comprehensive README with examples. Last activity appears recent given the Rails 7.1 gemfile support.

Low-to-moderate risk: single maintainer (chaps-io org), but well-established (Ryan Bates railscasts coverage indicates maturity). Main risks are tight Rails version coupling (requires 6.1+) and ORM-specific implementations (.orm/ subdirectories) could create fragmentation if maintainer steps back. Dependency footprint appears minimal (no Gemfile shown, suggesting few hard requirements).

Supporting latest Rails versions (7.0, 7.1 gemfiles indicate recent work). Migration upgrade generator suggests recent schema evolution. No open PR/issue data visible, but Rails version appraisals show active maintenance.

git clone https://github.com/chaps-io/public_activity.git
cd public_activity
bundle install
# Run tests or demos (Rakefile present)
bundle exec rake

Daily commands: No web server: this is a gem library. For development: bundle exec rake (Rakefile present). For integration in a Rails app: add gem 'public_activity' to Gemfile, run rails g public_activity:migration && rails db:migrate, then include PublicActivity::Model in target models.

• lib/public_activity/common.rb: Core module included in tracked models; defines tracked() macro and activity lifecycle hooks
• lib/public_activity/models/activity.rb: Base Activity model interface; real implementations in lib/public_activity/orm/{orm}/activity.rb
• lib/public_activity/config.rb: Runtime ORM selection via PublicActivity::Config.set { orm :mongoid }; controls which adapter loads
• lib/public_activity/orm/active_record/: Default ORM implementation; contains actual Activity model, trackable callbacks, and adapters
• lib/generators/public_activity/migration/templates/migration.rb: Schema definition for activities table; controls what fields are tracked (trackable_type, action, parameters, etc.)
• lib/public_activity/actions/: Creation.rb, update.rb, destruction.rb define hooks for tracking specific model lifecycle events

Adding ORM support: extend lib/public_activity/orm/{orm_name}/ with {activist,activity,adapter,trackable}.rb files. New tracking actions: add to lib/public_activity/actions/. Core tracking logic: lib/public_activity/common.rb includes PublicActivity::Model. Generator changes: lib/generators/public_activity/migration/templates/migration.rb controls schema.

1. ORM must be configured before models load (typically in config/initializers/public_activity.rb before app/models). 2) Activity records require a polymorphic trackable association—schema must include trackable_type and trackable_id columns. 3) MongoMapper/Mongoid branches have separate implementations; feature parity not guaranteed across ORMs. 4) Generators create app-specific migrations—running same generator twice may conflict.

• Polymorphic associations — PublicActivity uses trackable_type/trackable_id to store activities for ANY model type in a single table; understanding polymorphism is critical to extending the gem
• ORM adapter pattern — The gem abstracts ActiveRecord, Mongoid, and MongoMapper behind a common interface; knowing this pattern helps you add new database backends
• ActiveRecord callbacks — PublicActivity hooks into after_create, after_update, after_destroy callbacks to auto-track changes; you must understand Rails lifecycle to modify tracking behavior
• Rails generators — The gem includes custom generators (lib/generators/) to scaffold migrations; understanding generator structure is essential for adding new setup steps or schema upgrades
• Activity audit trail design — PublicActivity stores what changed (action field), who did it (actor), and key metadata; understanding immutable append-only log design informs how you query and display activities
• I18n (Internationalization) — README mentions I18n for translating activity descriptions per locale; the gem relies on Rails I18n to render user-facing activity messages

• audited/audited — Alternative Rails auditing gem; tracks model changes but emphasizes complete audit trail with version history, while PublicActivity is simpler and feed-focused
• paper_trail/paper_trail — Most popular Rails versioning gem; stores all attribute changes and allows rollback, whereas PublicActivity is lightweight and designed for user-facing activity feeds
• collectiveidea/acts-as-taggable-on — Companion gem often used with activity feeds to tag activities by category; integrates naturally with PublicActivity's polymorphic design
• rails/rails — Core framework dependency; PublicActivity relies on ActiveRecord callbacks, migrations, and view rendering from Rails 6.1+

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 comprehensive test suite for ORM adapters (ActiveRecord, Mongoid, MongoMapper)

The repo supports three different ORMs but the test directory only shows basic migrations. There's no evidence of comprehensive adapter tests in test/. Each ORM implementation in lib/public_activity/orm/{active_record,mongoid,mongo_mapper}/ needs dedicated test files to ensure feature parity and prevent regressions when Rails versions change.

• [ ] Create test/orm/ directory structure mirroring lib/public_activity/orm/
• [ ] Add test/orm/active_record_test.rb covering CRUD tracking for ActiveRecord adapter
• [ ] Add test/orm/mongoid_test.rb covering document operations for Mongoid
• [ ] Add test/orm/mongo_mapper_test.rb covering MongoMapper specifics
• [ ] Update Rakefile to run ORM-specific tests against each gemfile/{rails_6.1,rails_7.0,rails_7.1}.gemfile

Add GitHub Actions workflow for multi-ORM matrix testing

The repo has .github/workflows/main.yml and supports Rails 6.1+ with multiple ORMs (see gemfiles/ directory), but no evidence of CI that tests against all combinations. Need to add matrix testing to ensure ActiveRecord, Mongoid, and MongoMapper all work across Rails 6.1, 7.0, and 7.1.

• [ ] Update .github/workflows/main.yml to add a matrix strategy with: orm: [active_record, mongoid, mongo_mapper] and rails_version: [6.1, 7.0, 7.1]
• [ ] Configure each job to use the appropriate gemfile from gemfiles/rails_*.gemfile with ORM-specific test runs
• [ ] Add conditional steps to skip MongoDB tests if services aren't available, or add services: mongodb configuration
• [ ] Document in README.md which ORM/Rails combinations are officially tested

Refactor monolithic lib/public_activity/models/ files into domain-specific modules

lib/public_activity/models/trackable.rb and lib/public_activity/models/activity.rb likely contain mixed concerns (tracking logic, serialization, querying). These should be split into focused modules: lib/public_activity/models/trackable/{tracking.rb,recording.rb,lifecycle.rb} to improve maintainability and testability, especially given the three different ORM implementations.

• [ ] Analyze lib/public_activity/models/trackable.rb and lib/public_activity/models/activity.rb to identify distinct responsibilities (e.g., activity creation, querying, rendering)
• [ ] Create lib/public_activity/models/trackable/{tracking.rb, lifecycle.rb, querying.rb} extracting relevant methods
• [ ] Create lib/public_activity/models/activity/{recording.rb, rendering.rb, association.rb} for Activity model concerns
• [ ] Update lib/public_activity/orm/{active_record,mongoid,mongo_mapper}/trackable.rb to include new modules
• [ ] Add tests to verify behavior is unchanged after refactoring (test/refactoring/trackable_refactor_test.rb)

• Add test coverage for lib/public_activity/models/adapter.rb adapter interface—currently only ORM-specific implementations have tests. Create spec/models/adapter_spec.rb with abstract adapter pattern tests.
• Document custom activity types with a detailed example in README—track mentions only 'Custom activities' in TOC but README snippet cuts off. Create spec example showing how to use activity_key in different actions.
• Add integration test showing activity view rendering with I18n—README lists 'Activity views' and 'I18n' in TOC but no example shown. Create spec/integration/activity_view_spec.rb demonstrating render_activity() with locale-specific templates.

The public_activity gem has moderate security concerns. Primary risks include potential XSS vulnerabilities in view rendering, SQL injection in activity queries, missing input validation on tracked attributes, and insufficient

• High · Potential XSS vulnerability in view helpers — lib/public_activity/utility/view_helpers.rb. The file lib/public_activity/utility/view_helpers.rb likely contains rendering logic for activity data. Without inspecting the actual implementation, there's a significant risk that user-controlled activity data (actions, descriptions, or related model attributes) could be rendered without proper HTML escaping, leading to stored XSS attacks. Fix: Ensure all user-controlled data in activity views is properly escaped using Rails helpers (e.g., h(), sanitize() with allowed tags). Use <%= instead of <%== for template rendering. Add Content Security Policy headers.
• High · Potential SQL injection in activity filtering/querying — lib/public_activity/orm/active_record/activity.rb and lib/public_activity/models/activity.rb. The library provides activity tracking and querying capabilities (lib/public_activity/models/activity.rb and ORM adapters). If custom query filters or scopes accept user input without proper parameterization, SQL injection vulnerabilities could exist, particularly in the ActiveRecord adapter (lib/public_activity/orm/active_record/activity.rb). Fix: Always use parameterized queries and ActiveRecord query methods. Never interpolate user input into SQL queries. Use where(key: value) syntax instead of string interpolation. Validate and sanitize all filter parameters.
• Medium · Missing input validation on trackable models — lib/public_activity/models/trackable.rb and lib/public_activity/roles/tracked.rb. The library automatically tracks changes to models (lib/public_activity/models/trackable.rb and lib/public_activity/roles/tracked.rb). If the library stores serialized model attributes without validation, sensitive information or malicious payloads could be persisted in activity records. Fix: Implement whitelist-based filtering for tracked attributes. Exclude sensitive fields (passwords, tokens, API keys) from activity tracking. Add validation hooks to sanitize stored data before persistence.
• Medium · Potential insecure deserialization — lib/public_activity/orm/ (all adapters). The gem supports multiple ORMs (ActiveRecord, Mongoid, MongoMapper) and may serialize/deserialize data. If the library uses unsafe deserialization methods (e.g., YAML.load, Marshal.load without restrictions), remote code execution could be possible. Fix: Use safe deserialization methods (e.g., YAML.safe_load, JSON.parse). Avoid Marshal.load with untrusted data. Implement strict type checking for deserialized objects.
• Medium · Controller context exposure in activity records — lib/public_activity/utility/store_controller.rb. The library captures controller context (lib/public_activity/utility/store_controller.rb). If sensitive request data (parameters, headers, session data) is stored without filtering, this could expose user information in activity logs. Fix: Implement strict whitelist filtering for captured controller context. Never store sensitive parameters (passwords, tokens, credit cards) in activity records. Sanitize all captured request data.
• Low · Missing CSRF protection verification in generators — lib/generators/public_activity/. The migration generators (lib/generators/public_activity/) create database schema without explicitly documenting security considerations. If developers extend these generators without proper authorization checks, CSRF or unauthorized state-changing operations could occur. Fix: Document that CSRF protection should be enabled on all controllers that trigger activity tracking. Include guards in generated code to ensure only authorized requests are tracked.
• Low · Insufficient access control documentation — lib/public_activity/models/activity.rb and lib/public_activity/orm/active_record/activity.rb. The library provides activity querying capabilities but lacks explicit guidance on authorization/access control. Users may inadvertently expose activities they shouldn't (e.g., admin activities visible to regular users). Fix: Add authorization scope documentation and examples. Provide helper methods for filtering activities by user permissions. Include access control checks in view helpers to prevent unauthorized activity disclosure.

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.