HAL9000
7ab4172479
Update plugin_extension_points.feature and step definitions to reflect the addition of the ScopeChainResolverExtension as the 31st extension point. The PR added the extension point but forgot to update the existing test file that hardcoded the count as 30. ISSUES CLOSED: #5705
236 lines
12 KiB
Gherkin
236 lines
12 KiB
Gherkin
Feature: Plugin Extension Points Registration
|
|
The plugin infrastructure must register all 31 spec-defined extension
|
|
points with typed Protocol interfaces in the PluginManager.
|
|
|
|
Based on issue #939.
|
|
|
|
# -----------------------------------------------------------------------
|
|
# All 31 extension points are registered
|
|
# -----------------------------------------------------------------------
|
|
|
|
Scenario: All 31 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 31 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 31 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
|
|
And the "scope" 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 31
|
|
Then the TOTAL_EXTENSION_POINTS constant should equal 31
|
|
|
|
# -----------------------------------------------------------------------
|
|
# 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 31 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
|
|
|
|
Scenario: A concrete scope chain resolver satisfies ScopeChainResolverExtension
|
|
Given a concrete ScopeChainResolverExtension implementation
|
|
Then it should be recognized as a ScopeChainResolverExtension instance
|
|
And calling its scope chain resolver methods should succeed
|