Luis Mendes
3f5ca4e869
CI / benchmark-publish (pull_request) Has been skipped
CI / build (pull_request) Successful in 20s
CI / helm (pull_request) Successful in 22s
CI / lint (pull_request) Failing after 27s
CI / security (pull_request) Failing after 41s
CI / quality (pull_request) Successful in 3m41s
CI / typecheck (pull_request) Successful in 3m56s
CI / coverage (pull_request) Has been skipped
CI / benchmark-regression (pull_request) Has been skipped
CI / unit_tests (pull_request) Successful in 4m1s
CI / integration_tests (pull_request) Failing after 4m2s
CI / docker (pull_request) Has been skipped
CI / e2e_tests (pull_request) Successful in 20m59s
CI / status-check (pull_request) Failing after 1s
Registered all 30 spec-defined extension points in the ExtensionPointRegistry with typed Protocol interfaces for each category: context strategies (12), output renderers (3), validation runners (2), tool providers (2), skill providers (2), resource handlers (2), A2A transports (2), event handlers (2), config sources (2), and safety guardrails (1). Added extension_protocols.py with Protocol definitions and extension_catalog.py with the registration catalog. Wired context subsystem to query context.* extension points at initialization. ISSUES CLOSED: #939
230 lines
11 KiB
Gherkin
230 lines
11 KiB
Gherkin
Feature: Plugin Extension Points Registration
|
|
The plugin infrastructure must register all 30 spec-defined extension
|
|
points with typed Protocol interfaces in the PluginManager.
|
|
|
|
Based on issue #939.
|
|
|
|
# -----------------------------------------------------------------------
|
|
# All 30 extension points are registered
|
|
# -----------------------------------------------------------------------
|
|
|
|
Scenario: All 30 extension points are registered via register_all_extension_points
|
|
Given a fresh PluginManager for extension point registration
|
|
When I register all spec-defined extension points
|
|
Then exactly 30 extension points should be registered
|
|
|
|
Scenario: Extension point definitions are available as a tuple
|
|
When I retrieve the extension point definitions
|
|
Then I should get exactly 30 extension point definitions
|
|
And each definition should have a non-empty name
|
|
And each definition should have a protocol_type
|
|
And each definition should have a non-empty description
|
|
|
|
# -----------------------------------------------------------------------
|
|
# Extension point lookup by name
|
|
# -----------------------------------------------------------------------
|
|
|
|
Scenario: Extension point lookup by name returns the correct point
|
|
Given a PluginManager with all extension points registered
|
|
When I look up extension point "context.strategy"
|
|
Then the looked-up extension point name should be "context.strategy"
|
|
|
|
Scenario: Extension point lookup for pipeline component by name
|
|
Given a PluginManager with all extension points registered
|
|
When I look up extension point "context.pipeline_component.scorer"
|
|
Then the looked-up extension point name should be "context.pipeline_component.scorer"
|
|
|
|
Scenario: Extension point lookup for safety guardrail by name
|
|
Given a PluginManager with all extension points registered
|
|
When I look up extension point "safety.guardrail"
|
|
Then the looked-up extension point name should be "safety.guardrail"
|
|
|
|
Scenario: Lookup of non-existent extension point returns None
|
|
Given a PluginManager with all extension points registered
|
|
When I look up extension point "nonexistent.point"
|
|
Then the looked-up extension point should be None
|
|
|
|
# -----------------------------------------------------------------------
|
|
# Extension point lookup by category
|
|
# -----------------------------------------------------------------------
|
|
|
|
Scenario: Extension points grouped by category have correct counts
|
|
When I retrieve extension points grouped by category
|
|
Then the "context" category should have 12 extension points
|
|
And the "output" category should have 3 extension points
|
|
And the "validation" category should have 2 extension points
|
|
And the "tool" category should have 2 extension points
|
|
And the "skill" category should have 2 extension points
|
|
And the "resource" category should have 2 extension points
|
|
And the "a2a" category should have 2 extension points
|
|
And the "event" category should have 2 extension points
|
|
And the "config" category should have 2 extension points
|
|
And the "safety" category should have 1 extension points
|
|
|
|
# -----------------------------------------------------------------------
|
|
# Protocol type correctness
|
|
# -----------------------------------------------------------------------
|
|
|
|
Scenario: Context strategy extension point has correct protocol type
|
|
Given a PluginManager with all extension points registered
|
|
When I look up extension point "context.strategy"
|
|
Then the protocol type name should be "ContextStrategyExtension"
|
|
|
|
Scenario: Output renderer extension point has correct protocol type
|
|
Given a PluginManager with all extension points registered
|
|
When I look up extension point "output.renderer"
|
|
Then the protocol type name should be "OutputRendererExtension"
|
|
|
|
Scenario: Safety guardrail extension point has correct protocol type
|
|
Given a PluginManager with all extension points registered
|
|
When I look up extension point "safety.guardrail"
|
|
Then the protocol type name should be "SafetyGuardrailExtension"
|
|
|
|
# -----------------------------------------------------------------------
|
|
# Plugin registration via entry points
|
|
# -----------------------------------------------------------------------
|
|
|
|
Scenario: Plugin registration via entry points discovers no plugins by default
|
|
Given a fresh PluginManager for extension point registration
|
|
When I discover extension point plugins from group "cleveragents.ext.test"
|
|
Then the entry point discovered list should be empty
|
|
|
|
# -----------------------------------------------------------------------
|
|
# TOTAL_EXTENSION_POINTS constant
|
|
# -----------------------------------------------------------------------
|
|
|
|
Scenario: TOTAL_EXTENSION_POINTS constant equals 30
|
|
Then the TOTAL_EXTENSION_POINTS constant should equal 30
|
|
|
|
# -----------------------------------------------------------------------
|
|
# Context extension points wired to ACMSPipeline
|
|
# -----------------------------------------------------------------------
|
|
|
|
Scenario: ACMSPipeline reports context extension points when plugin manager is wired
|
|
Given a PluginManager with all extension points registered
|
|
And an ACMSPipeline wired with the plugin manager
|
|
Then the pipeline should report 12 context extension points
|
|
|
|
Scenario: ACMSPipeline reports no context extension points when no plugin manager
|
|
Given an ACMSPipeline without a plugin manager
|
|
Then the pipeline should report 0 context extension points
|
|
|
|
# -----------------------------------------------------------------------
|
|
# All extension protocols are runtime-checkable
|
|
# -----------------------------------------------------------------------
|
|
|
|
Scenario: All extension protocol types are runtime-checkable
|
|
When I retrieve all extension protocol types
|
|
Then every protocol should be runtime-checkable
|
|
|
|
# -----------------------------------------------------------------------
|
|
# Idempotent registration
|
|
# -----------------------------------------------------------------------
|
|
|
|
Scenario: Registering extension points twice does not duplicate
|
|
Given a fresh PluginManager for extension point registration
|
|
When I register all spec-defined extension points
|
|
And I register all spec-defined extension points again
|
|
Then exactly 30 extension points should be registered
|
|
|
|
# -----------------------------------------------------------------------
|
|
# Extension point registry_key matches category
|
|
# -----------------------------------------------------------------------
|
|
|
|
Scenario: Each extension point registry_key matches its category
|
|
When I retrieve the extension point definitions
|
|
Then each definition registry_key should match its name category prefix
|
|
|
|
# -----------------------------------------------------------------------
|
|
# Protocol implementation conformance
|
|
# -----------------------------------------------------------------------
|
|
|
|
Scenario: A concrete context strategy satisfies ContextStrategyExtension
|
|
Given a concrete ContextStrategyExtension implementation
|
|
Then it should be recognized as a ContextStrategyExtension instance
|
|
And calling its protocol methods should succeed
|
|
|
|
Scenario: A concrete pipeline component satisfies ContextPipelineComponentExtension
|
|
Given a concrete ContextPipelineComponentExtension implementation
|
|
Then it should be recognized as a ContextPipelineComponentExtension instance
|
|
And calling its pipeline component methods should succeed
|
|
|
|
Scenario: A concrete storage backend satisfies ContextStorageBackendExtension
|
|
Given a concrete ContextStorageBackendExtension implementation
|
|
Then it should be recognized as a ContextStorageBackendExtension instance
|
|
And calling its storage methods should succeed
|
|
|
|
Scenario: A concrete output renderer satisfies OutputRendererExtension
|
|
Given a concrete OutputRendererExtension implementation
|
|
Then it should be recognized as an OutputRendererExtension instance
|
|
And calling its renderer methods should succeed
|
|
|
|
Scenario: A concrete output materializer satisfies OutputMaterializerExtension
|
|
Given a concrete OutputMaterializerExtension implementation
|
|
Then it should be recognized as an OutputMaterializerExtension instance
|
|
|
|
Scenario: A concrete output format satisfies OutputFormatExtension
|
|
Given a concrete OutputFormatExtension implementation
|
|
Then it should be recognized as an OutputFormatExtension instance
|
|
|
|
Scenario: A concrete validation runner satisfies ValidationRunnerExtension
|
|
Given a concrete ValidationRunnerExtension implementation
|
|
Then it should be recognized as a ValidationRunnerExtension instance
|
|
|
|
Scenario: A concrete validation rule provider satisfies ValidationRuleProviderExtension
|
|
Given a concrete ValidationRuleProviderExtension implementation
|
|
Then it should be recognized as a ValidationRuleProviderExtension instance
|
|
|
|
Scenario: A concrete tool provider satisfies ToolProviderExtension
|
|
Given a concrete ToolProviderExtension implementation
|
|
Then it should be recognized as a ToolProviderExtension instance
|
|
|
|
Scenario: A concrete tool middleware satisfies ToolMiddlewareExtension
|
|
Given a concrete ToolMiddlewareExtension implementation
|
|
Then it should be recognized as a ToolMiddlewareExtension instance
|
|
|
|
Scenario: A concrete skill provider satisfies SkillProviderExtension
|
|
Given a concrete SkillProviderExtension implementation
|
|
Then it should be recognized as a SkillProviderExtension instance
|
|
|
|
Scenario: A concrete skill template satisfies SkillTemplateExtension
|
|
Given a concrete SkillTemplateExtension implementation
|
|
Then it should be recognized as a SkillTemplateExtension instance
|
|
|
|
Scenario: A concrete resource resolver satisfies ResourceResolverExtension
|
|
Given a concrete ResourceResolverExtension implementation
|
|
Then it should be recognized as a ResourceResolverExtension instance
|
|
|
|
Scenario: A concrete resource type handler satisfies ResourceTypeHandlerExtension
|
|
Given a concrete ResourceTypeHandlerExtension implementation
|
|
Then it should be recognized as a ResourceTypeHandlerExtension instance
|
|
|
|
Scenario: A concrete A2A transport satisfies A2ATransportExtension
|
|
Given a concrete A2ATransportExtension implementation
|
|
Then it should be recognized as an A2ATransportExtension instance
|
|
|
|
Scenario: A concrete A2A extension method satisfies A2AExtensionMethodExtension
|
|
Given a concrete A2AExtensionMethodExtension implementation
|
|
Then it should be recognized as an A2AExtensionMethodExtension instance
|
|
|
|
Scenario: A concrete event handler satisfies EventHandlerExtension
|
|
Given a concrete EventHandlerExtension implementation
|
|
Then it should be recognized as an EventHandlerExtension instance
|
|
|
|
Scenario: A concrete event filter satisfies EventFilterExtension
|
|
Given a concrete EventFilterExtension implementation
|
|
Then it should be recognized as an EventFilterExtension instance
|
|
|
|
Scenario: A concrete config source satisfies ConfigSourceExtension
|
|
Given a concrete ConfigSourceExtension implementation
|
|
Then it should be recognized as a ConfigSourceExtension instance
|
|
|
|
Scenario: A concrete config validator satisfies ConfigValidatorExtension
|
|
Given a concrete ConfigValidatorExtension implementation
|
|
Then it should be recognized as a ConfigValidatorExtension instance
|
|
|
|
Scenario: A concrete safety guardrail satisfies SafetyGuardrailExtension
|
|
Given a concrete SafetyGuardrailExtension implementation
|
|
Then it should be recognized as a SafetyGuardrailExtension instance
|
|
And calling its guardrail methods should succeed
|