refactor: make BaseProvider a BaseModel with discriminated union

[greysonlalonde]

Summary

• Replace BaseProvider Protocol with BaseModel + ABC so providers serialize/deserialize natively via pydantic
• Add provider_type Literal field to JsonProvider and SqliteProvider
• Use discriminated union on CheckpointConfig.provider so the correct provider class is reconstructed from checkpoint JSON
• Fixes TypeError: Expected a BaseProvider instance, got <class 'str'> on checkpoint restore

Test plan

• CheckpointConfig(provider=SqliteProvider()) round-trips through model_dump_json / model_validate_json
• Crew.from_checkpoint(path, provider=SqliteProvider()) works
• Existing checkpoint tests pass

---

Note

Medium Risk
Medium risk because it changes how checkpoint providers are typed/validated/serialized via Pydantic, which can affect checkpoint round-tripping and restore paths across existing stored snapshots.

Overview
Refactors checkpoint provider serialization by replacing BaseProvider from a Protocol with an abstract pydantic.BaseModel carrying a provider_type discriminator.

CheckpointConfig.provider is now a discriminated union (JsonProvider | SqliteProvider) keyed by provider_type, and both providers add a provider_type Literal field so checkpoint configs can round-trip through JSON and reconstruct the correct provider implementation during restore.

^{Reviewed by Cursor Bugbot for commit 45e05e2. Bugbot is set up for automated code reviews on this repo. Configure here.}

[iris-clawd]

Review: BaseProvider → BaseModel with discriminated union

Good fix for the serialization round-trip issue. Protocol → BaseModel+ABC is the right call when you need Pydantic to own the serialization.

🟡 Extensibility for custom providers

The discriminated union on CheckpointConfig.provider is now a concrete JsonProvider | SqliteProvider. Third-party providers can't be plugged in without modifying this type annotation. The old Protocol approach allowed any conforming object.

For alpha this is fine — you only have two providers. But if custom providers are a planned use case, you'd want a registry pattern or Union that can be extended (e.g., entry points, or a class method that returns the updated Annotated type). Worth noting in docs.

🟡 BaseProvider.provider_type default

BaseProvider has provider_type: str = "base" as a non-abstract field. A subclass that forgets to override it with a Literal would still pass validation but break the discriminator at the CheckpointConfig level (Pydantic would fail to match "base" to any union member). Making provider_type abstract or removing the default would catch this at definition time. Minor since you only have two concrete providers.

🟢 Looks good

• Discriminated union via provider_type Literal is clean Pydantic v2 pattern
• @abstractmethod on all five methods is correct — forces implementation
• Removes the hacky __get_pydantic_core_schema__ workaround
• Fixes the actual bug (TypeError on checkpoint restore)

Solid refactor. 💬 171

[iris-clawd]

Approved. ✅

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 45e05e2. Configure here.}