HAL9000
f9c308c541
Created src/cleveragents/shared/output_format.py - a new shared module with format_data() function that provides JSON/YAML/plain/table serialization without any CLI dependencies. Fixed reverse dependency in plan_apply_service.py - changed import from cleveragents.cli.formatting to cleveragents.shared.output_format (the most critical architectural violation: Application layer importing from Presentation layer). Added .importlinter configuration file with rules to enforce: - No Application->Presentation (CLI) reverse dependencies - CLI->Application boundary violations (with current exceptions documented) Added import-linter>=2.0 to dev dependencies in pyproject.toml. Added BDD feature file features/a2a_boundary_enforcement.feature with 10 scenarios testing the boundary enforcement and step definitions. ISSUES CLOSED: #9962
60 lines
2.6 KiB
Gherkin
60 lines
2.6 KiB
Gherkin
Feature: A2A architectural boundary enforcement
|
|
As a developer
|
|
I want to verify that the CLI layer does not bypass the A2A boundary
|
|
So that the architecture remains clean and maintainable
|
|
|
|
Background:
|
|
Given the source directory exists at "src/cleveragents"
|
|
|
|
Scenario: Application layer does not import from CLI (Presentation) layer
|
|
Given the application services directory exists
|
|
When I scan all application service modules for CLI imports
|
|
Then no application service module should import from "cleveragents.cli"
|
|
|
|
Scenario: plan_apply_service uses shared output_format instead of CLI formatting
|
|
Given the plan_apply_service module exists
|
|
When I inspect plan_apply_service imports
|
|
Then it should not import from "cleveragents.cli.formatting"
|
|
And it should import from "cleveragents.shared.output_format"
|
|
|
|
Scenario: shared output_format module has no CLI dependencies
|
|
Given the shared output_format module exists
|
|
When I inspect shared output_format imports
|
|
Then it should not import from "cleveragents.cli"
|
|
|
|
Scenario: format_data function handles JSON format
|
|
Given the shared output_format module is imported
|
|
When I call format_data with a dict and format "json"
|
|
Then the result should be valid JSON
|
|
And the result should contain the expected keys
|
|
|
|
Scenario: format_data function handles YAML format
|
|
Given the shared output_format module is imported
|
|
When I call format_data with a dict and format "yaml"
|
|
Then the result should be valid YAML
|
|
|
|
Scenario: format_data function handles plain format
|
|
Given the shared output_format module is imported
|
|
When I call format_data with a dict and format "plain"
|
|
Then the result should contain key-value pairs
|
|
|
|
Scenario: format_data function handles table format
|
|
Given the shared output_format module is imported
|
|
When I call format_data with a list of dicts and format "table"
|
|
Then the result should contain column headers
|
|
|
|
Scenario: format_data function falls back to JSON for unknown format
|
|
Given the shared output_format module is imported
|
|
When I call format_data with a dict and format "unknown"
|
|
Then the result should be valid JSON
|
|
|
|
Scenario: format_data handles empty list for table format
|
|
Given the shared output_format module is imported
|
|
When I call format_data with an empty list and format "table"
|
|
Then the result should be "(empty)"
|
|
|
|
Scenario: format_data handles nested dict values
|
|
Given the shared output_format module is imported
|
|
When I call format_data with a nested dict and format "plain"
|
|
Then the result should contain nested key-value pairs
|