Feature: A2A facade optional parameter validation
  As a developer using the A2A local facade
  I want optional parameters to be validated before being passed to services
  So that invalid inputs are rejected early with clear error messages

  # -------------------------------------------------------------------
  # _handle_registry_list_tools — namespace validation
  # -------------------------------------------------------------------

  Scenario: list_tools with valid namespace succeeds
    Given an opt-val facade with a mock ToolRegistry
    When I dispatch opt-val operation "registry.list_tools" with params {"namespace": "local"}
    Then the opt-val response status should be "ok"
    And the opt-val response data should contain key "tools"

  Scenario: list_tools with None namespace succeeds
    Given an opt-val facade with a mock ToolRegistry
    When I dispatch opt-val operation "registry.list_tools" with params {}
    Then the opt-val response status should be "ok"
    And the opt-val response data should contain key "tools"

  Scenario: list_tools with empty string namespace returns error
    Given an opt-val facade with a mock ToolRegistry
    When I dispatch opt-val operation "registry.list_tools" with params {"namespace": ""}
    Then the opt-val response status should be "error"
    And the opt-val response error message should contain "namespace must be a non-empty string"

  Scenario: list_tools with non-string namespace returns error
    Given an opt-val facade with a mock ToolRegistry
    When I dispatch opt-val operation "registry.list_tools" with params {"namespace": 42}
    Then the opt-val response status should be "error"
    And the opt-val response error message should contain "namespace must be a string or None"

  Scenario: list_tools with no registry returns empty tools list
    Given an opt-val facade with no services
    When I dispatch opt-val operation "registry.list_tools" with params {"namespace": "local"}
    Then the opt-val response status should be "ok"
    And the opt-val response data should contain key "tools"

  # -------------------------------------------------------------------
  # _handle_registry_list_resources — type_name validation
  # -------------------------------------------------------------------

  Scenario: list_resources with valid type_name succeeds
    Given an opt-val facade with a mock ResourceRegistryService
    When I dispatch opt-val operation "registry.list_resources" with params {"type_name": "git-checkout"}
    Then the opt-val response status should be "ok"
    And the opt-val response data should contain key "resources"

  Scenario: list_resources with None type_name succeeds
    Given an opt-val facade with a mock ResourceRegistryService
    When I dispatch opt-val operation "registry.list_resources" with params {}
    Then the opt-val response status should be "ok"
    And the opt-val response data should contain key "resources"

  Scenario: list_resources with empty string type_name returns error
    Given an opt-val facade with a mock ResourceRegistryService
    When I dispatch opt-val operation "registry.list_resources" with params {"type_name": ""}
    Then the opt-val response status should be "error"
    And the opt-val response error message should contain "type_name must be a non-empty string"

  Scenario: list_resources with non-string type_name returns error
    Given an opt-val facade with a mock ResourceRegistryService
    When I dispatch opt-val operation "registry.list_resources" with params {"type_name": 99}
    Then the opt-val response status should be "error"
    And the opt-val response error message should contain "type_name must be a string or None"

  Scenario: list_resources with no service returns empty resources list
    Given an opt-val facade with no services
    When I dispatch opt-val operation "registry.list_resources" with params {"type_name": "git-checkout"}
    Then the opt-val response status should be "ok"
    And the opt-val response data should contain key "resources"

  # -------------------------------------------------------------------
  # _handle_plan_create — arguments validation
  # -------------------------------------------------------------------

  Scenario: plan.create with valid dict arguments succeeds
    Given an opt-val facade with a mock PlanLifecycleService
    When I dispatch opt-val operation "plan.create" with params {"action_name": "build", "arguments": {"target": "all"}}
    Then the opt-val response status should be "ok"
    And the opt-val response data key "status" should equal "created"

  Scenario: plan.create with None arguments succeeds
    Given an opt-val facade with a mock PlanLifecycleService
    When I dispatch opt-val operation "plan.create" with params {"action_name": "build"}
    Then the opt-val response status should be "ok"
    And the opt-val response data key "status" should equal "created"

  Scenario: plan.create with non-dict arguments returns error
    Given an opt-val facade with a mock PlanLifecycleService
    When I dispatch opt-val operation "plan.create" with params {"action_name": "build", "arguments": "not-a-dict"}
    Then the opt-val response status should be "error"
    And the opt-val response error message should contain "arguments must be a dict or None"

  # -------------------------------------------------------------------
  # _handle_plan_create — created_by validation
  # -------------------------------------------------------------------

  Scenario: plan.create with valid created_by succeeds
    Given an opt-val facade with a mock PlanLifecycleService
    When I dispatch opt-val operation "plan.create" with params {"action_name": "build", "created_by": "alice"}
    Then the opt-val response status should be "ok"
    And the opt-val response data key "status" should equal "created"

  Scenario: plan.create with None created_by succeeds
    Given an opt-val facade with a mock PlanLifecycleService
    When I dispatch opt-val operation "plan.create" with params {"action_name": "build"}
    Then the opt-val response status should be "ok"
    And the opt-val response data key "status" should equal "created"

  Scenario: plan.create with empty string created_by returns error
    Given an opt-val facade with a mock PlanLifecycleService
    When I dispatch opt-val operation "plan.create" with params {"action_name": "build", "created_by": ""}
    Then the opt-val response status should be "error"
    And the opt-val response error message should contain "created_by must be a non-empty string"

  Scenario: plan.create with non-string created_by returns error
    Given an opt-val facade with a mock PlanLifecycleService
    When I dispatch opt-val operation "plan.create" with params {"action_name": "build", "created_by": 123}
    Then the opt-val response status should be "error"
    And the opt-val response error message should contain "created_by must be a string or None"