[gkosmo]

Tracks rcrewai 0.8.0.

The upgrade did not break anything

Bumping the dependency and running the existing suite against 0.8.0 passed 221/221 unchanged. The release is genuinely additive for this engine, so this PR is feature adoption rather than repair.

Added

• Checkpointing. ActiveRecordCheckpointStore persists crew checkpoints to the new rcrewai_checkpoints table, implementing the gem's save/load/list/delete contract the way ActiveRecordStateStore already does for Flow. Records are stored verbatim as JSON, so a record written by any store implementation round-trips identically.
• Resume. crew.resume_sync(execution) / resume_async replay tasks that already completed instead of paying for them again. Executions record run_id/parent_run_id, so a resumed run links back to the one it continues and RCrewAI::Checkpoint.lineage walks the chain. Off by default, with a per-crew checkpoint_enabled column.
• LLM interceptors. config.llm_before_request / llm_after_response. Worth noting: the gem forwards hooks only through LLMClient.for_provider, but agents resolve their client via LLMClient.resolve, which does not — so hooks configured on the engine would silently never fire on a per-agent LLM. Registering them on the built client covers every path.
• Providers. openai_compatible, bedrock, snowflake, openai_responses needed no engine change (provider values pass through), but are now spec-covered and documented in the generated initializer.

Fixed

Both reproduced with a failing test first.

• Crew inputs never reached the gem. CrewExecutionJob persisted the execution's inputs but called rcrew.execute without them, so before_kickoff hooks and Crew#last_inputs always saw {} and no task could interpolate an input. Pre-existing, unrelated to the upgrade.
• Concurrent runs of the same agent shared one span stack. The collector keyed open spans by agent name, so one run's tool call could nest under the other run's iteration, and its usage/text/errors could land on the wrong span. 0.8 stamps every event with the id of its enclosing run span — probing the real gem confirmed this is a flat per-run id, not a nested tree, so it is for attribution rather than nesting. The collector now scopes its bookkeeping by it. Events without one (older streams, and the engine's own crew/agent spans) keep the previous behavior.

Verification

• 258 examples, 0 failures (was 221).
• The 012 migration applied against a simulated pre-0.8 schema, which is the path existing installs actually take.
• The packaged gem genuinely contains the new files — they were untracked, so git ls-files in the gemspec would have shipped them missing.

Upgrading

rails rcrew_ai_rails:install:migrations
rails db:migrate

Adds rcrewai_checkpoints, rcrewai_crews.checkpoint_enabled, and run_id/parent_run_id on executions. Checkpointing is off by default, so nothing changes until enabled.

Known issue, left alone

The suite is order-dependent: --order random fails ~87 examples on the original code too, because real_migrate_spec.rb swaps the global DB connection. It predates this work and deserves its own fix.

🤖 Generated with Claude Code

https://claude.ai/code/session_0123Ahvp1Cd6DoAgfr5bsYm2