Performs routine dependency updates and introduces ruby-gem-update skill and ruby-gem-updater subagent

.opencode/agents/ruby-gem-updater.md

@@ -0,0 +1,68 @@
+---
+description: Execute Ruby gem updates with version checking, breaking change analysis, and testing
+mode: subagent
+model: minimax-coding-plan/MiniMax-M2.5
+permission:
+  skill:
+    "ruby-gem-update": "allow"
+    "rspec-testing": "allow"
+    "*": "deny"
+tools:
+  bash: true
+  read: true
+  edit: true
+  write: true
+  grep: true
+  glob: true
+  webfetch: true
+---
+
+You are a Ruby gem update specialist focused on safely updating gems in the Linkvan API project.
+
+## Your Responsibilities
+
+### Gem Updates
+
+1. **Version Checking**
+   - Identify current gem version from Gemfile
+   - Fetch latest version from RubyGems
+   - Check GitHub release notes for breaking changes
+
+2. **Security Advisory Check**
+   - Check for security vulnerabilities in the gem
+   - Prioritize security updates
+
+3. **Breaking Change Analysis**
+   - Review release notes for breaking changes
+   - Check if codebase uses deprecated features
+   - Plan any required code migrations
+
+4. **Execution**
+   - Update Gemfile version constraint
+   - Run bundle update
+   - Verify installation
+   - Run tests to confirm
+
+### Workflow
+
+1. When user asks to update a gem:
+   - Use `ruby-gem-update` skill for the complete workflow
+   - Always present a plan to the user before making changes
+   - Get explicit approval before updating
+
+2. After update:
+   - Report results clearly
+   - Note any issues if tests fail
+
+## Guidelines
+
+- Always check Ruby version compatibility
+- Review breaking changes for major version jumps
+- Run `bin/rspec` after every update (per AGENTS.md)
+- Report results clearly to user
+
+## Important Notes
+
+- Test command: `bin/rspec` (not `bundle exec rspec`)
+- Use pessimistic version constraints (`~> X.Y`) for minor updates
+- For major updates, review all breaking changes carefully

.opencode/skills/ruby-gem-update/SKILL.md

@@ -0,0 +1,219 @@
+---
+name: ruby-gem-update
+description: Standardized Ruby gem update workflow with version checking, breaking change analysis, security advisory detection, and testing
+license: MIT
+compatibility: opencode
+metadata:
+  audience: developers
+  language: ruby
+---
+
+## When to Use This Skill
+
+- User asks to update a gem (e.g., "update puma", "upgrade faker", "bump devise version")
+- Performing routine gem maintenance
+- Responding to security advisories
+- User wants to check if a gem needs updating
+
+## Prerequisites
+
+- This skill works with Ruby/Rails projects using Bundler
+- Test command: `bin/rspec` (per AGENTS.md conventions)
+
+## Complete Workflow
+
+### Phase 1: Discovery
+
+#### Step 1.1: Identify Current Version
+- Read the Gemfile to find the gem and its current version constraint
+- Also check `.ruby-lsp/Gemfile.lock` if present
+- Note the current installed version from Gemfile.lock
+
+#### Step 1.2: Check if Gem is Already a Dependency
+Before adding or updating a gem explicitly in Gemfile, check Gemfile.lock to see if it's already pulled in as a dependency:
+- If the gem appears under another gem's dependencies, it's already installed
+- Only add/update explicitly if:
+  - The user specifically requests it
+  - There's a version constraint conflict that requires it
+  - The gem needs a different version than what the dependency pulls in
+
+#### Step 1.3: Check RubyGems for Latest Version
+- Fetch: `https://rubygems.org/gems/<gem-name>`
+- Record:
+  - Latest version number
+  - Required Ruby version
+  - License
+  - Runtime dependencies
+
+#### Step 1.4: Check GitHub Release Notes
+- Fetch: `https://github.com/<owner>/<repo>/releases`
+- Look for:
+  - Breaking changes between current and latest version
+  - Deprecated/removed features
+  - Security fixes
+  - Ruby version requirement changes
+- Check major versions (v6.x → v7.x) carefully for breaking changes
+
+### Phase 2: Security Advisory Check
+
+#### Step 2.1: Check RubySec Advisories
+- Fetch: `https://rubysec.com/` or search for advisories on the gem
+- Check: `https://github.com/rubygems/rubygems/tree/master/security`
+- Also check: Gem's GitHub security tab
+
+#### Step 2.2: Evaluate Risk
+- If security advisory exists:
+  - Note severity (Critical/High/Medium/Low)
+  - Determine if update is urgent
+- If no advisory, proceed with normal update process
+
+### Phase 3: Breaking Change Analysis
+
+#### Step 3.1: Parse Release Notes
+For each version between current and latest:
+- Look for "Breaking Changes" sections
+- Note renamed APIs (e.g., `on_worker_boot` → `before_worker_boot`)
+- Note removed deprecated features
+- Note configuration changes
+
+#### Step 3.2: Check Codebase Usage
+- If deprecated features found in release notes:
+  - Search codebase with grep for the deprecated API
+  - Note what needs to be updated
+  - Prepare migration steps
+
+### Phase 4: Planning
+
+#### Step 4.1: Create Update Plan
+Present to user with:
+- Current version vs latest version
+- Version type (patch/minor/major)
+- Ruby requirement compatibility
+- Breaking changes found
+- Security advisories (if any)
+- Code changes needed (if any)
+- Proposed steps
+
+#### Step 4.2: Get User Approval
+Wait for user confirmation before proceeding with:
+- Gemfile changes
+- Bundle updates
+- Code migrations
+
+### Phase 5: Execution
+
+#### Step 5.1: Update Gemfile
+- Edit Gemfile to change version constraint
+- Use pessimistic version constraint for minor updates: `~> X.Y`
+- Use specific version for major updates: `= X.0.0`
+
+#### Step 5.2: Run Bundle Update
+```bash
+bundle update <gem-name>
+```
+
+#### Step 5.3: Verify Installation
+```bash
+bundle exec <gem-name> --version
+```
+Or for gems without CLI:
+```bash
+bundle exec ruby -e "require '<gem-name>'; puts <GemName>::VERSION"
+```
+
+#### Step 5.4: Run Tests
+```bash
+bin/rspec
+```
+
+### Phase 6: Reporting
+
+#### Step 6.1: Report Results
+- New version installed
+- Test results (pass/fail)
+- Any issues encountered
+
+#### Step 6.2: Handle Failures
+If tests fail:
+1. Analyze failure message
+2. Check if related to gem update
+3. If breaking change caused failure:
+   - Document the issue
+   - Suggest fix to user
+   - Do NOT proceed without user approval
+
+## Version Constraint Guide
+
+| Update Type | Constraint Example | Notes |
+|-------------|---------------------|-------|
+| Patch only | `~> 1.0.0` | Allows 1.0.x |
+| Minor | `~> 1.4` | Allows 1.x (x >= 4) |
+| Major | `= 2.0.0` | Lock to specific version |
+| Latest | `~> 3.6` | Allows any 3.x |
+
+## Common Version Upgrade Patterns
+
+### Minor/Patch Updates
+- Generally safe
+- Run tests to verify
+- Check release notes for any notable changes
+
+### Major Updates
+- Review breaking changes carefully
+- May require code updates
+- Test thoroughly
+- Consider incremental updates (e.g., 6.x → 7.x → 8.x)
+
+### Security Updates
+- Prioritize based on severity
+- May require immediate action
+- Check for exploit availability
+
+## Example: Complete Update Workflow
+
+```
+User: Update puma
+
+Assistant (using this skill):
+1. Finds current: puma ~> 6.4.2
+2. Checks RubyGems: latest 7.2.0
+3. Checks GitHub releases:
+   - v7.0.0: Breaking changes (hook renames, Ruby 3.0+)
+   - v7.1.0: Bugfixes
+   - v7.2.0: Performance improvements
+4. Checks security: None found
+5. Checks codebase: config/puma.rb uses no deprecated hooks
+6. Presents plan to user
+
+User: proceed
+
+Assistant:
+1. Updates Gemfile: puma ~> 7.2
+2. bundle update puma
+3. Verifies: puma 7.2.0
+4. bin/rspec → 1914 examples, 0 failures
+5. Reports success
+```
+
+## Important Notes
+
+1. **Always get user approval** before making changes
+2. **Check Ruby version compatibility** before major updates
+3. **Review breaking changes** for major version jumps
+4. **Run tests** after every update
+5. **Report results** clearly to user
+
+## Testing
+
+After any gem update, always run:
+```bash
+bin/rspec
+```
+
+This follows the project's AGENTS.md convention for test execution.
+
+## Error Handling
+
+- If bundle update fails: Analyze error, check gem dependencies
+- If tests fail: Investigate cause, report to user
+- If breaking changes found: Stop and consult user before proceeding

AGENTS.md

@@ -13,3 +13,5 @@
 - Admin interface: `/admin/dashboard`
 - ViewComponent tests: `type: :component`
 - System specs: Capybara + Puma
+- Running tests: `bin/rspec`
+- Running Rails commands: `bin/rails`

Gemfile

@@ -8,7 +8,7 @@ gem "rails", "~> 8.1.0"
 # Use postgresql as the database for Active Record
 gem "pg", "~> 1.6.2"
 # Use Puma as the app server
-gem "puma", "~> 6.4.2"
+gem "puma", "~> 7.2"
 # Build JSON APIs with ease. Read more: https://github.com/rails/jbuilder
 #gem "jbuilder", "~> 2.7"
 # Use Redis adapter to run Action Cable in production
@@ -62,7 +62,7 @@ group :development, :test do
 end
 
 # Faker gem - available in development/test, and in production when ALLOW_FAKE_DATA is set
-gem "faker", "~> 3.4.2", groups: [:development, :test].tap { |groups| 
+gem "faker", "~> 3.6", groups: [:development, :test].tap { |groups| 
   groups << :production if ENV['ALLOW_FAKE_DATA'] == 'true' 
 }
 
@@ -74,15 +74,15 @@ group :development do
   # gem "spring"
 
   # powerful developer console.
-  gem "pry", "~> 0.14.2"
+  gem "pry", "~> 0.16.0"
   gem "pry-rails"
-  gem "pry-stack_explorer", "~> 0.6.1"
+  gem "pry-stack_explorer", "~> 0.6.2"
   gem "pry-remote"
-  gem "pry-byebug"
+  gem "pry-byebug", "~> 3.12.0"
 
   # Display performance information such as SQL time and flame graphs for each request in your browser.
   # Can be configured to work on production as well see: https://github.com/MiniProfiler/rack-mini-profiler/blob/master/README.md
-  gem "rack-mini-profiler", "~> 3.3.1"
+  gem "rack-mini-profiler", "~> 4.0"
   gem "memory_profiler"
   gem "stackprof"