@phase2 @a2a @coverage-boost Feature: A2A clients coverage boost As a developer I want complete coverage of Protocol default bodies and stub validation branches So that all code paths in cleveragents.a2a.clients are exercised # ----------------------------------------------------------------------- # Protocol default method bodies (the `...` expressions) # ----------------------------------------------------------------------- Scenario: ServerClient protocol health_check default body executes Given a concrete subclass of ServerClient protocol When I call health_check on the concrete server client Then the call should complete without error Scenario: ServerClient protocol get_version default body executes Given a concrete subclass of ServerClient protocol When I call get_version on the concrete server client Then the call should complete without error Scenario: RemoteExecutionClient protocol execute_plan default body executes Given a concrete subclass of RemoteExecutionClient protocol When I call execute_plan on the concrete execution client Then the call should complete without error Scenario: RemoteExecutionClient protocol get_plan_status default body executes Given a concrete subclass of RemoteExecutionClient protocol When I call get_plan_status on the concrete execution client Then the call should complete without error Scenario: RemoteExecutionClient protocol cancel_plan default body executes Given a concrete subclass of RemoteExecutionClient protocol When I call cancel_plan on the concrete execution client Then the call should complete without error Scenario: AuthClient protocol authenticate default body executes Given a concrete subclass of AuthClient protocol When I call authenticate on the concrete auth client Then the call should complete without error Scenario: AuthClient protocol validate_token default body executes Given a concrete subclass of AuthClient protocol When I call validate_token on the concrete auth client Then the call should complete without error # ----------------------------------------------------------------------- # Stub validation branches — empty string inputs # ----------------------------------------------------------------------- Scenario: StubRemoteExecutionClient get_plan_status rejects empty plan_id Given a fresh StubRemoteExecutionClient for coverage When I call get_plan_status with empty plan_id on the stub Then a ValueError should be raised with plan_id validation message Scenario: StubRemoteExecutionClient cancel_plan rejects empty plan_id Given a fresh StubRemoteExecutionClient for coverage When I call cancel_plan with empty plan_id on the stub Then a ValueError should be raised with plan_id validation message Scenario: StubAuthClient validate_token rejects empty token Given a fresh StubAuthClient for coverage When I call validate_token with empty token on the stub Then a ValueError should be raised with token validation message # ----------------------------------------------------------------------- # Stub validation branches — non-string type inputs # ----------------------------------------------------------------------- Scenario: StubRemoteExecutionClient get_plan_status rejects non-string plan_id Given a fresh StubRemoteExecutionClient for coverage When I call get_plan_status with a non-string plan_id on the stub Then a ValueError should be raised with plan_id validation message Scenario: StubRemoteExecutionClient cancel_plan rejects non-string plan_id Given a fresh StubRemoteExecutionClient for coverage When I call cancel_plan with a non-string plan_id on the stub Then a ValueError should be raised with plan_id validation message Scenario: StubAuthClient validate_token rejects non-string token Given a fresh StubAuthClient for coverage When I call validate_token with a non-string token on the stub Then a ValueError should be raised with token validation message