The dev lockfile is 51 gems behind its own constraints (json 2.7→3.0, zeitwerk 2.6→2.8, async 2.24→2.37) and Dependabot's monthly bundler batch never arrived #64

bundle update on main (1d28f84), touching nothing but Gemfile.lock and honouring every cap already in the Gemfile, moves 51 gems. The ones that matter are runtime, and they're what every fresh gem install agentic already resolves to while CI tests the old numbers:

Dev side: standard 1.32→1.57 (rubocop 1.57→1.91, so Ruby 3.4 syntax finally lints), rspec 3.13.0→3.13.2 (core 3.13.6), webmock 3.23→3.30, simplecov 1.0→1.3, rake 13.2→13.4. The last sweep was #24 on 2026-08-30 and it was deliberately conservative; nothing has moved the lock since except two CVE patches and #33.

Suite on the refreshed lock (Ruby 4.0.2, this machine):

• As-is: 0 examples, 5 errors occurred outside of examples, every one require "base64". The refresh drops the orphan base64 (0.2.0) entry the lock has been carrying with no dependent, and authentication_system.rb has a dead require "base64" that only ever loaded because of that orphan. That's require "agentic" can't load ArtifactGraph or AuthenticationSystem outside the dev bundle: rgl and base64 are required by lib/ but declared nowhere a consumer sees #63; the fix is deleting one line.
• With that line gone: 1391 examples, 1 failure. The failure is event_dispatcher_integration_spec.rb:291 (total_time < 0.1), the wall-clock assertion that fails identically on untouched main here (documented in Bound the six unconstrained runtime dependencies; lock ruby-openai 8.3.0 #29). json 3.0, zeitwerk 2.8, dry-schema 1.16, async 2.37 all pass.

Dependabot never showed up. #43 merged the grouped-monthly config on 2026-09-17. A config merge triggers an immediate run, and the 1st of the month triggers the scheduled one; neither produced a bundler PR, and the only Dependabot PRs this repo has ever had are the two actions/checkout bumps (#9, #19). With seven explicit gems bumpable inside their constraints, "nothing to do" isn't the explanation. The job log lives only in Insights → Dependency graph → Dependabot, which I can't read from here. Worth a glance when you're on the page; I'm not filing that as its own ask.

What I'd do: one PR, bundle update within existing constraints plus the one-line base64 deletion the refresh forces, CHANGELOG untouched (lockfile isn't shipped). CI's 3.2.4 leg is what gates it; locally that leg's resolution is identical except where a gem's floor is 3.3 (none of the runtime ones are).

Class: deps-minor (L1)
Minerva's lean: Refresh now in one PR; CI testing zeitwerk 2.6 and json 2.7 while consumers run 2.8 and 3.0 is the same blind spot #42 named, and this half needs no cap change to close.

Labels: loop:deps, status:analyzed