Files
cleveragents-core/features/virtual_builtin_actors.feature
T
hurui200320 8dc55655e9
CI / push-validation (push) Successful in 41s
CI / helm (push) Successful in 42s
CI / benchmark-publish (push) Failing after 56s
CI / build (push) Successful in 1m6s
CI / lint (push) Successful in 1m13s
CI / quality (push) Successful in 1m34s
CI / typecheck (push) Successful in 2m12s
CI / security (push) Successful in 2m13s
CI / e2e_tests (push) Successful in 3m45s
CI / integration_tests (push) Successful in 3m57s
CI / unit_tests (push) Successful in 4m53s
CI / docker (push) Successful in 1m34s
CI / coverage (push) Successful in 11m27s
CI / status-check (push) Successful in 3s
CI / benchmark-publish (pull_request) Has been skipped
CI / helm (pull_request) Successful in 32s
CI / push-validation (pull_request) Successful in 33s
CI / build (pull_request) Successful in 53s
CI / lint (pull_request) Successful in 59s
CI / quality (pull_request) Successful in 1m28s
CI / security (pull_request) Successful in 1m29s
CI / typecheck (pull_request) Successful in 1m32s
CI / e2e_tests (pull_request) Successful in 4m1s
CI / integration_tests (pull_request) Successful in 5m4s
CI / unit_tests (pull_request) Successful in 5m51s
CI / docker (pull_request) Successful in 1m27s
CI / coverage (pull_request) Successful in 11m51s
CI / status-check (pull_request) Successful in 3s
feat(actor): make built-in actors virtual, resolved on-demand from provider registry
Replace the DB-persistence approach for built-in actors with in-memory virtual
resolution. Built-in actors (e.g. openai/gpt-4o, anthropic/claude-sonnet) are
now resolved on-demand from ProviderRegistry at query time and merged with
persisted custom actors — no database writes occur for built-in actors.

Key changes:
- Add ActorRegistry._resolve_virtual_builtin_actors(): generates virtual Actor
  objects in-memory from configured providers (is_built_in=True, id=None)
- ActorRegistry.list()/list_actors(): merges virtual built-ins with custom DB
  actors; custom actors win on name collision; result sorted alphabetically
- ActorRegistry.get()/get_actor(): DB-first, virtual built-in fallback,
  NotFoundError if neither
- ActorRegistry.remove()/remove_actor(): rejects virtual built-in names with
  ValidationError
- ActorRegistry.set_default_actor(): stores only the actor name string via new
  actor_preferences singleton table; no actor row created for virtual built-ins
- ActorRegistry.get_default_actor(): reads preference name, resolves via
  DB→virtual chain, returns actor with is_default=True
- Remove ensure_built_in_actors() entirely — 20+ call sites cleaned up including
  plan.py
- Remove ActorRepository.upsert_built_in() — no longer needed
- Remove is_built_in from ActorModel DB column (kept on Actor domain model for
  virtual actors)
- New Alembic migration m10_001_virtual_builtin_actors: drops is_built_in column,
  adds actor_preferences singleton table
- Add ActorService.set_default_actor_name() and get_default_actor_name() for
  preference storage without requiring a DB actor row
- Update 15+ Behave step files and 5 feature files; add new
  features/virtual_builtin_actors.feature with 8 scenarios covering list, show,
  remove, set-default, get-default, no-DB-writes guarantees
- Rewrite tests/actor/test_registry_builtin_yaml.py: TestEnsureBuiltInActorsWithYaml
  → TestResolveVirtualBuiltinActors plus new TestListActors, TestGetActor,
  TestRemoveActor, TestDefaultActor test classes

Quality gates: lint ✓, typecheck ✓, unit_tests ✓ (15674 scenarios), coverage ✓
(97.10%), integration_tests ✓ (1997 tests)

ISSUES CLOSED: #10923
2026-04-30 10:56:21 +00:00

58 lines
2.8 KiB
Gherkin

@virtual_builtin
Feature: Virtual built-in actors resolved on-demand from provider registry
As an agent user
I want built-in actors to appear immediately after init (when providers are configured)
So that I can run actors without prior write operations
Background:
Given a virtual actor registry with configured providers:
| type | name | model |
| openai | openai | gpt-4o |
| anthropic | anthropic | claude-3-opus |
Scenario: Actor list shows built-in actors immediately after init
When I list virtual actors
Then the virtual actor list should contain "openai/gpt-4o"
And the virtual actor list should contain "anthropic/claude-3-opus"
And the virtual actor list should show built-in flag for "openai/gpt-4o"
And no database writes should have occurred
Scenario: Actor show works for virtual built-in without prior materialization
When I show virtual actor "openai/gpt-4o"
Then the virtual actor result should have name "openai/gpt-4o"
And the virtual actor result should be marked as built-in
And no database writes should have occurred
Scenario: Actor remove rejects virtual built-in with clear error
When I try to remove virtual actor "openai/gpt-4o"
Then a virtual actor ValidationError should be raised
And the virtual builtin error message should mention "built-in"
Scenario: Actor set-default persists name for virtual built-in without DB row
When I set default virtual actor to "openai/gpt-4o"
Then the virtual actor default name should be stored as "openai/gpt-4o"
And no actor row should be created in the database
Scenario: Actor get-default resolves virtual built-in from stored preference
Given the default actor preference is set to "openai/gpt-4o"
When I get the default virtual actor
Then the virtual actor result should have name "openai/gpt-4o"
And the virtual actor result should be marked as built-in
And the virtual actor result should be marked as default
Scenario: Actor list shows no DB writes occur
When I list virtual actors
Then the virtual actor service upsert_actor should not have been called
And the virtual actor service set_default_actor should not have been called
Scenario: Actor list with no configured providers returns empty
Given a virtual actor registry with no configured providers
When I list virtual actors via no-provider registry
Then the virtual no-provider actor list should be empty
Scenario: Custom actor takes precedence over virtual built-in with same name
Given a custom DB actor named "openai/gpt-4o" exists
When I list virtual actors
Then the virtual actor list should contain "openai/gpt-4o"
And the "openai/gpt-4o" actor in list should not be built-in