fix(validation): replace positional key=value args with --key value named options in validation attach command #3880

Merged
HAL9000 merged 7 commits from bugfix/validation-attach-named-option-format into master 2026-06-14 21:54:17 +00:00
5 changed files with 505 additions and 18 deletions
@@ -0,0 +1,171 @@
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
"""Step definitions for validation attach named options TDD tests.
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Verifies that ``agents validation attach`` accepts ``--key value`` named
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
option format for extra validation arguments, as required by the spec.
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
"""
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
from __future__ import annotations
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
from unittest.mock import MagicMock, patch
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
from behave import given, then, when
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
from behave.runner import Context
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
from typer.testing import CliRunner
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
from cleveragents.cli.commands.validation import app as validation_app
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
_ATTACHMENT_ULID = "01NAMEDOPT000000000000001"
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
# ---------------------------------------------------------------------------
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
# Background
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
# ---------------------------------------------------------------------------
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
@given("a validation attach named options test runner")
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
def step_named_options_runner(context: Context) -> None:
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
"""Set up the CLI runner for named options tests."""
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
context.named_opts_runner = CliRunner()
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
@given("a validation attach named options mocked environment")
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
def step_named_options_mock_env(context: Context) -> None:
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
"""Set up the mocked service for named options tests."""
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
context.named_opts_mock_service = MagicMock()
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
context.named_opts_patcher = patch(
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
"cleveragents.cli.commands.validation._get_tool_registry_service",
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
return_value=context.named_opts_mock_service,
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
)
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
context.named_opts_patcher.start()
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
context.add_cleanup(context.named_opts_patcher.stop)
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
context.named_opts_result = None
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
# ---------------------------------------------------------------------------
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
# Given
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
# ---------------------------------------------------------------------------
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
@given('a genuine validation "{name}" is ready for named option attach')
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
def step_named_opts_validation_ready(context: Context, name: str) -> None:
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
"""Configure the mock service to return a successful attachment."""
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
mock_attachment = MagicMock()
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
mock_attachment.attachment_id = _ATTACHMENT_ULID
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
mock_attachment.validation_name = name
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
mock_attachment.resource_id = "git-checkout/my-repo"
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
mock_attachment.mode = "required"
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
mock_attachment.project_name = None
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
mock_attachment.plan_id = None
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
mock_attachment.created_at = "2026-01-01T00:00:00"
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
context.named_opts_mock_service.attach_validation.return_value = mock_attachment
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
context.named_opts_mock_service.attach_validation.side_effect = None
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
# ---------------------------------------------------------------------------
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
# When
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
# ---------------------------------------------------------------------------
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
@when('I invoke validation attach "{resource}" "{validation}" with args "{args_str}"')
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
def step_named_opts_invoke_with_args(
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
context: Context, resource: str, validation: str, args_str: str
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
) -> None:
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
"""Invoke the validation attach CLI command with extra named options."""
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
# Split args_str into individual tokens (space-separated)
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
extra_tokens = args_str.split()
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
cmd = ["attach", resource, validation, "--format", "plain", *extra_tokens]
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
context.named_opts_result = context.named_opts_runner.invoke(
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
validation_app,
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
cmd,
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
)
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
context.last_result = context.named_opts_result
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
@when('I invoke validation attach "{resource}" "{validation}" with no extra args')
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
def step_named_opts_invoke_no_args(
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
context: Context, resource: str, validation: str
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
) -> None:
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
"""Invoke the validation attach CLI command without extra named options."""
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
cmd = ["attach", resource, validation, "--format", "plain"]
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
context.named_opts_result = context.named_opts_runner.invoke(
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
validation_app,
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
cmd,
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
)
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
context.last_result = context.named_opts_result
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
# ---------------------------------------------------------------------------
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
# Then: success
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
# ---------------------------------------------------------------------------
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
@then("the named option attach should succeed")
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
def step_named_opts_attach_succeeds(context: Context) -> None:
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
"""Verify the attach command exited with code 0."""
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
result = context.named_opts_result
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
assert result is not None
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
assert result.exit_code == 0, (
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
f"Expected exit 0 (success), got {result.exit_code}. Output: {result.output}"
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
)
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
@then('the service should have received coverage-threshold as "{expected_val}"')
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
def step_named_opts_received_coverage_threshold(
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
context: Context, expected_val: str
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
) -> None:
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
"""Verify the service received coverage_threshold in the args dict.
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
The CLI converts hyphens in option names to underscores when forwarding
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
to the service layer (``--coverage-threshold`` → ``coverage_threshold``).
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
"""
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
call_kwargs = context.named_opts_mock_service.attach_validation.call_args
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
assert call_kwargs is not None, "attach_validation was not called"
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
args_dict = call_kwargs.kwargs.get("args") or {}
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
assert "coverage_threshold" in args_dict, (
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
f"Expected 'coverage_threshold' in args, got: {args_dict}"
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
)
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
assert args_dict["coverage_threshold"] == expected_val, (
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
f"Expected coverage_threshold={expected_val!r}, got {args_dict['coverage_threshold']!r}"
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
)
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
@then('the service should have received threshold as "{expected_val}"')
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
def step_named_opts_received_threshold(context: Context, expected_val: str) -> None:
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
"""Verify the service received threshold in the args dict."""
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
call_kwargs = context.named_opts_mock_service.attach_validation.call_args
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
assert call_kwargs is not None, "attach_validation was not called"
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
args_dict = call_kwargs.kwargs.get("args") or {}
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
assert "threshold" in args_dict, f"Expected 'threshold' in args, got: {args_dict}"
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
assert args_dict["threshold"] == expected_val, (
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
f"Expected threshold={expected_val!r}, got {args_dict['threshold']!r}"
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
)
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
@then('the service should have received strict as "{expected_val}"')
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
def step_named_opts_received_strict(context: Context, expected_val: str) -> None:
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
"""Verify the service received strict in the args dict."""
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
call_kwargs = context.named_opts_mock_service.attach_validation.call_args
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
assert call_kwargs is not None, "attach_validation was not called"
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
args_dict = call_kwargs.kwargs.get("args") or {}
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
assert "strict" in args_dict, f"Expected 'strict' in args, got: {args_dict}"
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
assert args_dict["strict"] == expected_val, (
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
f"Expected strict={expected_val!r}, got {args_dict['strict']!r}"
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
)
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
# ---------------------------------------------------------------------------
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
# Then: rejection
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
# ---------------------------------------------------------------------------
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
@then("the named option attach should be rejected")
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
def step_named_opts_attach_rejected(context: Context) -> None:
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
"""Verify the attach command exited with a non-zero code."""
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
result = context.named_opts_result
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
assert result is not None
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
assert result.exit_code != 0, (
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
f"Expected non-zero exit code (rejection), got {result.exit_code}. "
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
f"Output: {result.output}"
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
)
Review

Once the CLI keeps normalising the names, the service should still see coverage_threshold (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?

Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
@@ -0,0 +1,40 @@
Feature: Validation attach accepts --key value named option format
As a CleverAgents user
I want the "agents validation attach" command to accept --key value named options
So that I can use the spec-compliant format for extra validation arguments
Background:
Given a validation attach named options test runner
And a validation attach named options mocked environment
# --- Spec-compliant named option format ---
Scenario: Attach with a single named option --coverage-threshold 90
Given a genuine validation "local/coverage-check" is ready for named option attach
When I invoke validation attach "git-checkout/my-repo" "local/coverage-check" with args "--coverage-threshold 90"
Then the named option attach should succeed
And the service should have received coverage-threshold as "90"
Scenario: Attach with multiple named options
Given a genuine validation "local/lint-check" is ready for named option attach
When I invoke validation attach "git-checkout/my-repo" "local/lint-check" with args "--threshold 70 --strict true"
Then the named option attach should succeed
And the service should have received threshold as "70"
And the service should have received strict as "true"
Scenario: Attach without any extra named options still works
Given a genuine validation "local/basic-check" is ready for named option attach
When I invoke validation attach "git-checkout/my-repo" "local/basic-check" with no extra args
Then the named option attach should succeed
Scenario: Attach with a bare token (not --key value) is rejected
Given a genuine validation "local/coverage-check" is ready for named option attach
When I invoke validation attach "git-checkout/my-repo" "local/coverage-check" with args "coverage-threshold=90"
Then the named option attach should be rejected
And the rejection output should contain "Invalid argument format"
Scenario: Attach with a named option missing its value is rejected
Given a genuine validation "local/coverage-check" is ready for named option attach
When I invoke validation attach "git-checkout/my-repo" "local/coverage-check" with args "--coverage-threshold"
Then the named option attach should be rejected
And the rejection output should contain "Missing value for option"
@@ -0,0 +1,224 @@
"""Helper script for validation_attach_named_options.robot E2E tests.
Each subcommand is a self-contained check that prints a sentinel on success.
Tests that ``agents validation attach`` accepts ``--key value`` named option
format for extra validation arguments, as required by the spec.
"""
from __future__ import annotations
import sys
from collections.abc import Callable
from pathlib import Path
from unittest.mock import MagicMock, patch
# Ensure local source tree is importable
_SRC = str(Path(__file__).resolve().parents[1] / "src")
if _SRC not in sys.path:
sys.path.insert(0, _SRC)
from helpers_common import reset_global_state # noqa: E402
from typer.testing import CliRunner # noqa: E402
from cleveragents.cli.commands.validation import app as validation_app # noqa: E402
runner = CliRunner()
_ATTACHMENT_ULID = "01NAMEDOPT000000000000001"
def _make_mock_attachment(validation_name: str, resource_id: str) -> MagicMock:
"""Create a mock attachment object."""
mock_attachment = MagicMock()
mock_attachment.attachment_id = _ATTACHMENT_ULID
mock_attachment.validation_name = validation_name
mock_attachment.resource_id = resource_id
mock_attachment.mode = "required"
mock_attachment.project_name = None
mock_attachment.plan_id = None
mock_attachment.created_at = "2026-01-01T00:00:00"
return mock_attachment
# ---------------------------------------------------------------------------
# Subcommands
# ---------------------------------------------------------------------------
def attach_with_coverage_threshold() -> None:
"""Verify that --coverage-threshold 90 named option is accepted and forwarded."""
mock_svc = MagicMock()
mock_svc.attach_validation.return_value = _make_mock_attachment(
"local/coverage-check", "git-checkout/my-repo"
)
with patch(
"cleveragents.cli.commands.validation._get_tool_registry_service",
return_value=mock_svc,
):
result = runner.invoke(
validation_app,
[
"attach",
"git-checkout/my-repo",
"local/coverage-check",
"--coverage-threshold",
"90",
"--format",
"plain",
],
)
if result.exit_code != 0:
print(
f"FAIL: exit={result.exit_code} output={result.output!r} "
f"exception={result.exception!r}"
)
sys.exit(1)
# Verify the service received the correct args dict
call_kwargs = mock_svc.attach_validation.call_args
if call_kwargs is None:
print("FAIL: attach_validation was not called")
sys.exit(1)
args_dict = call_kwargs.kwargs.get("args") or {}
if args_dict.get("coverage_threshold") != "90":
print(f"FAIL: expected args={{'coverage_threshold': '90'}}, got {args_dict!r}")
sys.exit(1)
print("validation-attach-named-option-coverage-threshold-ok")
def attach_with_multiple_named_options() -> None:
"""Verify that multiple --key value named options are all forwarded."""
mock_svc = MagicMock()
mock_svc.attach_validation.return_value = _make_mock_attachment(
"local/lint-check", "git-checkout/my-repo"
)
with patch(
"cleveragents.cli.commands.validation._get_tool_registry_service",
return_value=mock_svc,
):
result = runner.invoke(
validation_app,
[
"attach",
"git-checkout/my-repo",
"local/lint-check",
"--threshold",
"70",
"--strict",
"true",
"--format",
"plain",
],
)
if result.exit_code != 0:
print(
f"FAIL: exit={result.exit_code} output={result.output!r} "
f"exception={result.exception!r}"
)
sys.exit(1)
call_kwargs = mock_svc.attach_validation.call_args
if call_kwargs is None:
print("FAIL: attach_validation was not called")
sys.exit(1)
args_dict = call_kwargs.kwargs.get("args") or {}
if args_dict.get("threshold") != "70":
print(f"FAIL: expected threshold='70', got {args_dict!r}")
sys.exit(1)
if args_dict.get("strict") != "true":
print(f"FAIL: expected strict='true', got {args_dict!r}")
sys.exit(1)
print("validation-attach-named-option-multiple-ok")
def attach_without_extra_args() -> None:
"""Verify that attach without extra named options still works."""
mock_svc = MagicMock()
mock_svc.attach_validation.return_value = _make_mock_attachment(
"local/basic-check", "git-checkout/my-repo"
)
with patch(
"cleveragents.cli.commands.validation._get_tool_registry_service",
return_value=mock_svc,
):
result = runner.invoke(
validation_app,
[
"attach",
"git-checkout/my-repo",
"local/basic-check",
"--format",
"plain",
],
)
if result.exit_code != 0:
print(
f"FAIL: exit={result.exit_code} output={result.output!r} "
f"exception={result.exception!r}"
)
sys.exit(1)
print("validation-attach-named-option-no-extra-args-ok")
def attach_with_positional_key_value_rejected() -> None:
"""Verify that old-style positional key=value format is rejected."""
mock_svc = MagicMock()
mock_svc.attach_validation.return_value = _make_mock_attachment(
"local/coverage-check", "git-checkout/my-repo"
)
with patch(
"cleveragents.cli.commands.validation._get_tool_registry_service",
return_value=mock_svc,
):
result = runner.invoke(
validation_app,
[
"attach",
"git-checkout/my-repo",
"local/coverage-check",
"coverage-threshold=90",
"--format",
"plain",
],
)
# Must be rejected (non-zero exit) and output must mention "Invalid argument format"
if result.exit_code != 0 and "Invalid argument format" in result.output:
print("validation-attach-positional-key-value-rejected-ok")
else:
print(
f"FAIL: exit={result.exit_code} "
f"output={result.output!r} "
f"(expected non-zero exit and 'Invalid argument format' in output)"
)
sys.exit(1)
# ---------------------------------------------------------------------------
# Dispatcher
# ---------------------------------------------------------------------------
_COMMANDS: dict[str, Callable[[], None]] = {
"attach-with-coverage-threshold": attach_with_coverage_threshold,
"attach-with-multiple-named-options": attach_with_multiple_named_options,
"attach-without-extra-args": attach_without_extra_args,
"attach-with-positional-key-value-rejected": (
attach_with_positional_key_value_rejected
),
}
if __name__ == "__main__":
if len(sys.argv) < 2 or sys.argv[1] not in _COMMANDS:
print(f"Usage: {sys.argv[0]} <{'|'.join(_COMMANDS)}>")
sys.exit(1)
reset_global_state()
fn = _COMMANDS[sys.argv[1]]
fn()
@@ -0,0 +1,44 @@
*** Settings ***
Documentation Integration tests for the validation attach named option format.
... Verifies that ``agents validation attach`` accepts ``--key value``
... named option format for extra validation arguments, as required
... by the specification.
Resource ${CURDIR}/common.resource
Suite Setup Setup Test Environment With Database Isolation
Suite Teardown Cleanup Test Environment
*** Variables ***
${HELPER} ${CURDIR}/helper_validation_attach_named_options.py
*** Test Cases ***
Validation Attach Accepts Named Option Coverage Threshold
[Documentation] Attaching with --coverage-threshold 90 must succeed and forward the arg.
${result}= Run Process ${PYTHON} ${HELPER} attach-with-coverage-threshold cwd=${WORKSPACE} timeout=120s on_timeout=kill
Log ${result.stdout}
Log ${result.stderr}
Should Be Equal As Integers ${result.rc} 0
Should Contain ${result.stdout} validation-attach-named-option-coverage-threshold-ok
Validation Attach Accepts Multiple Named Options
[Documentation] Attaching with multiple --key value pairs must succeed and forward all args.
${result}= Run Process ${PYTHON} ${HELPER} attach-with-multiple-named-options cwd=${WORKSPACE} timeout=120s on_timeout=kill
Log ${result.stdout}
Log ${result.stderr}
Should Be Equal As Integers ${result.rc} 0
Should Contain ${result.stdout} validation-attach-named-option-multiple-ok
Validation Attach Works Without Extra Named Options
[Documentation] Attaching without extra named options must still succeed.
${result}= Run Process ${PYTHON} ${HELPER} attach-without-extra-args cwd=${WORKSPACE} timeout=120s on_timeout=kill
Log ${result.stdout}
Log ${result.stderr}
Should Be Equal As Integers ${result.rc} 0
Should Contain ${result.stdout} validation-attach-named-option-no-extra-args-ok
Validation Attach Rejects Positional Key Equals Value Format
[Documentation] Old-style positional key=value format must be rejected with a clear error.
${result}= Run Process ${PYTHON} ${HELPER} attach-with-positional-key-value-rejected cwd=${WORKSPACE} timeout=120s on_timeout=kill
Log ${result.stdout}
Log ${result.stderr}
Should Be Equal As Integers ${result.rc} 0
Should Contain ${result.stdout} validation-attach-positional-key-value-rejected-ok
+26 -18
View File
@@ -306,8 +306,8 @@ def attach(
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
local/api-repo local/run-tests --coverage-threshold 90
"""
try:
# Parse extra named options from ctx.args (--key value format).
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
# ctx.args contains all unrecognised tokens after Typer's own parsing.
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
# Parse extra named options from ctx.args (--key value pairs).
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
# ctx.args contains the remaining tokens after known options are consumed.
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
extra_args: dict[str, str] | None = None
raw_extra = list(ctx.args)
if raw_extra:
@@ -315,25 +315,33 @@ def attach(
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
i = 0
while i < len(raw_extra):
token = raw_extra[i]
if not token.startswith("--"):
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
if token.startswith("--"):
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
key = token[2:].replace(
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
"-", "_"
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
) # --coverage-threshold → coverage_threshold
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
if (
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
not key
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
): # pragma: no cover - Click consumes bare '--' before ctx.args
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
console.print(
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
"[red]Invalid option:[/red] bare '--' is not allowed"
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
)
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
raise typer.Abort()
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
# Next token is the value (must not be another --flag)
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
if i + 1 >= len(raw_extra) or raw_extra[i + 1].startswith("--"):
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
console.print(
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
f"[red]Missing value for option:[/red] {token} "
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
"(expected --key value, e.g. --coverage-threshold 90)"
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
)
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
raise typer.Abort()
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
val = raw_extra[i + 1]
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
extra_args[key] = val
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
i += 2
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
else:
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
console.print(
f"[red]Invalid argument format:[/red] {token!r} "
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
"(expected --key value named option format, "
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
"e.g. --coverage-threshold 90)"
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
f"[red]Invalid argument format:[/red] {token} "
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
"(expected --key value named option)"
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
)
raise typer.Abort()
key = token[2:].replace(
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
"-", "_"
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
) # --coverage-threshold → coverage_threshold
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
if i + 1 >= len(raw_extra) or raw_extra[i + 1].startswith("--"):
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
console.print(
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
f"[red]Missing value for option:[/red] {token} "
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
"(expected --key value, e.g. --coverage-threshold 90)"
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
)
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
raise typer.Abort()
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
val = raw_extra[i + 1]
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
extra_args[key] = val
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
i += 2
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
service = _get_tool_registry_service()
attachment = service.attach_validation(
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?
Review

We still need the guard that treats a subsequent -- token as a missing value for the current option. Right now agents validation attach … --threshold --strict true would accept '--strict' as the value for --threshold and then complain about the trailing 'true', which produces a confusing error message. Could we keep the raw_extra[i + 1].startswith("--") check (and corresponding error) so we flag the right option as missing its value?

We still need the guard that treats a subsequent `--` token as a missing value for the current option. Right now `agents validation attach … --threshold --strict true` would accept `'--strict'` as the value for `--threshold` and then complain about the trailing `'true'`, which produces a confusing error message. Could we keep the `raw_extra[i + 1].startswith("--")` check (and corresponding error) so we flag the right option as missing its value?
Review

The spec still normalises CLI option names to underscore keys in the args map (see docs/specification.md, "agents validation attach" section where the CLI output shows Args: coverage_threshold=90). Forwarding coverage-threshold here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling extra_args?

The spec still normalises CLI option names to underscore keys in the args map (see `docs/specification.md`, "agents validation attach" section where the CLI output shows `Args: coverage_threshold=90`). Forwarding `coverage-threshold` here diverges from that contract and will break downstream consumers. Could we keep the hyphen→underscore conversion when assembling `extra_args`?