fix(validation): replace positional key=value args with --key value named options in validation attach command #3880
@@ -0,0 +1,171 @@
|
||||
|
|
||||
"""Step definitions for validation attach named options TDD tests.
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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.
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
"""
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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"
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
# ---------------------------------------------------------------------------
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
# ---------------------------------------------------------------------------
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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")
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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:
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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."""
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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()
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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")
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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:
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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."""
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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()
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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(
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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",
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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,
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
)
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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()
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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)
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
# ---------------------------------------------------------------------------
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
# ---------------------------------------------------------------------------
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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')
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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:
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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."""
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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()
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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"
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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"
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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"
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
# ---------------------------------------------------------------------------
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
# ---------------------------------------------------------------------------
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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}"')
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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(
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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:
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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."""
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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)
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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()
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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]
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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(
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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,
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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,
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
)
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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')
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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(
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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:
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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."""
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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"]
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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(
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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,
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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,
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
)
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
# ---------------------------------------------------------------------------
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
# ---------------------------------------------------------------------------
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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")
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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:
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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."""
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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, (
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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}"
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
)
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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}"')
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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(
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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:
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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.
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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``).
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
"""
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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"
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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 {}
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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, (
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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}"
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
)
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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, (
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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}"
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
)
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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}"')
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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:
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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."""
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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"
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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 {}
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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}"
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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, (
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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}"
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
)
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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}"')
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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:
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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."""
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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"
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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 {}
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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}"
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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, (
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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}"
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
)
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
# ---------------------------------------------------------------------------
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
# ---------------------------------------------------------------------------
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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")
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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:
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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."""
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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, (
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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}. "
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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}"
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could we update this expectation—and the Robot helper assertions—to look for the underscore form so the tests continue to match the documented API?
|
||||
)
|
||||
|
HAL9000
commented
Once the CLI keeps normalising the names, the service should still see Once the CLI keeps normalising the names, the service should still see `coverage_threshold` (underscore) in its args. Could 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
|
||||
@@ -306,8 +306,8 @@ def attach(
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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`?
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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).
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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.
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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).
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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.
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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(
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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`?
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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("--"):
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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("--"):
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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(
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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`?
|
||||
"-", "_"
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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 (
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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(
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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"
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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`?
|
||||
)
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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()
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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)
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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("--"):
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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(
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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} "
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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)"
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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`?
|
||||
)
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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()
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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]
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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:
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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} "
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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, "
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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)"
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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} "
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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)"
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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(
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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`?
|
||||
"-", "_"
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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("--"):
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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(
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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} "
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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)"
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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`?
|
||||
)
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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()
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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]
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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(
|
||||
|
||||
|
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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`?
HAL9000
commented
We still need the guard that treats a subsequent 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?
HAL9000
commented
The spec still normalises CLI option names to underscore keys in the args map (see 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`?
|
||||
Once the CLI keeps normalising the names, the service should still see
coverage_threshold(underscore) in its args. Could 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?