cleveragents-core/features/cli_config_jinja_port.feature

Feature: Actor-first port of v2 CLI/config/Jinja suites
  As a developer migrating v2 flows
  I want actor-only CLI and YAML template coverage
  So that v3 matches the v2 behaviors without provider/model flags

  Scenario: Unknown command reports helpful error
    When I run the CleverAgents CLI with "invalid-command"
    Then the CLI command should fail
    And the CLI output should contain "No such command"
    And the exit code should be 2

  Scenario: Plan help highlights actor requirement
    When I run the CleverAgents CLI with "plan --help"
    Then the exit code should be 0
    And the CLI output should contain "actor"
    And the CLI output should not contain "--provider"
    And the CLI output should not contain "--model"

  Scenario: Render templated YAML with loops and context
    Given the YAML template engine is initialized for coverage
    And I have a YAML string with inline Jinja2 templates:
      """
      items:
        {% for item in items %}
        - {{ item }}
        {% endfor %}
      context_value: {{ context.existing }}
      """
    And I have a template context with list items
    When I render the YAML with context
    Then the rendered YAML should be parsed into a mapping
    And the rendered mapping should include loop results and merged context

  Scenario: Deferred template renders invalid YAML raises error
    Given the YAML template engine is initialized for coverage
    And I have invalid templated YAML for deferred rendering:
      """
      agent:
        name: {{ name
      """
    When I load YAML content without context for deferred rendering
    Then a YAML error should be raised for deferred loading

  Scenario: Rendering malformed mapping with colons surfaces YAML error
    Given the YAML template engine is initialized for coverage
    And I have a templated YAML that renders malformed mapping:
      """
      config: {{ value_with_colons }}
      """
    And I have a template context with colon rich value
    When I render the YAML with context
    Then a YAML parsing error should be raised after attempting fixes

   Scenario: Preprocess adds indentation hints for loops
     Given the YAML template engine is initialized for coverage
     And I have a YAML string with for loops requiring preprocessing:
       """
       agents:
         {% for item in items %}
         - name: {{ item }}
         {% endfor %}
       """
     When I preprocess the YAML content for rendering
     Then indentation hints should be present after the loop line

   Scenario: Sum filter raises for non-summable values
     Given the YAML template engine is initialized for coverage
     And I have non-summable values for the sum filter
     When I apply the sum filter expecting an error
     Then a ValueError should be raised for the sum filter

   Scenario: Utility functions are evaluated during render
     Given the YAML template engine is initialized for coverage
     And I have template using utility functions:
       """
       utilities:
         range_values: {{ range(3) | list }}
         abs_value: {{ abs(-4) }}
         round_value: {{ round(3.14159, 2) }}
       """
     When I process with complete render context utilities
     Then utility functions should be evaluated

   Scenario: Retry parsing recovers after transient YAML error
     Given the YAML template engine is initialized for coverage
     And I have YAML with a placeholder causing parse retry:
       """
       result: {{ value }}
       """
     And I have a template context for retry parsing
     When I render YAML with a transient YAML error on first parse
     Then the rendering retry should yield a mapping result

   Scenario: Retry parsing raises when repaired YAML is not a mapping
     Given the YAML template engine is initialized for coverage
     And I have YAML with a placeholder causing parse retry:
       """
       result: {{ value }}
       """
     And I have a template context for retry parsing
     When rendering retry returns non-mapping after YAML error
     Then a ValueError should be raised for non-mapping retry