hurui200320
2005b8ef82
CI / push-validation (push) Successful in 18s
CI / build (push) Successful in 19s
CI / helm (push) Successful in 24s
CI / lint (push) Successful in 29s
CI / security (push) Successful in 1m11s
CI / e2e_tests (push) Successful in 2m56s
CI / quality (push) Successful in 3m40s
CI / typecheck (push) Successful in 3m59s
CI / integration_tests (push) Successful in 4m3s
CI / unit_tests (push) Successful in 4m55s
CI / docker (push) Successful in 10s
CI / coverage (push) Successful in 10m44s
CI / status-check (push) Successful in 1s
CI / benchmark-regression (push) Has been skipped
CI / benchmark-publish (push) Successful in 1h13m28s
## Summary Replaces all 234 bare `@skip` occurrences across 82 Behave feature files with the correct TDD issue-capture tagging system described in CONTRIBUTING.md § Bug Fix Workflow. Previously, the noxfile ran Behave with `--tags=not @skip`, silently excluding all `@skip`-tagged scenarios from every CI run. These tests never ran, never inverted results via the `@tdd_expected_fail` mechanism, and never contributed to coverage — defeating the purpose of TDD issue-capture testing. Every `@skip` occurrence had a commented-out hint line immediately above it showing the intended proper tags (e.g., `# @tdd_issue @tdd_issue_4272 @tdd_expected_fail @skip`), confirming they were all intended for conversion. ## Changes ### Mechanical conversion (234 replacements across 82 files) - Extracted the proper TDD tags from the comment hint above each `@skip` line, removed `@skip` from the tag set, and replaced the `@skip` line with those tags. - Removed the now-redundant comment hint lines alongside each replacement. ### Bug-fixed scenarios — `@tdd_expected_fail` removed (84 scenarios) - After conversion, ran `nox -s unit_tests` to identify which newly-enabled `@tdd_expected_fail` scenarios now **pass** (their referenced bugs have already been fixed). Removed `@tdd_expected_fail` from those 84 scenarios and their corresponding feature-level tags, leaving only the permanent `@tdd_issue @tdd_issue_<N>` regression-guard tags. - Affected features include: `tdd_tool_runner_env_precedence`, `tdd_automation_profile_session_leak`, `tls_certificate_check`, `project_create_persist`, `resource_type_bootstrap_*`, and 18 others. ### Noxfile cleanup - Removed all four `--tags=not @skip` arguments from `noxfile.py` (unit_tests and coverage sessions). With zero `@skip` tags remaining in the codebase, this filter was dead code and its presence would mislead future maintainers into thinking `@skip` is still a supported escape mechanism. ### Regression guard files - Split the regression guards into two focused files: - `tdd_regression_guards_exec_env.feature` for bug #4281 (exec-env precedence) - `tdd_regression_guards_session_list.feature` for bug #4271 (session list summary) - Each file carries only its own `@tdd_issue` tags at the feature level, avoiding cross-contamination via Behave tag inheritance. The `Background` step (`session-list-summary mock`) only appears in the session-list file where it is actually needed. ### Duplicate tag cleanup - Removed duplicate `@tdd_issue @tdd_issue_4287` tag lines in `tdd_skill_add_regression.feature` (lines 20 and 29). ### Inline comment for retained `@tdd_expected_fail` - Added inline comment in `ci_workflow_validation.feature:134` explaining why this specific #4227 scenario retains `@tdd_expected_fail` despite #4227 being closed (CI YAML does not encode threshold as a machine-readable value). ### Known edge cases — `@tdd_expected_fail` retained (closed issues, fix on master, scenarios still fail) The following issues are **closed** and their fixes **are on master**, but the specific test assertions still fail because the fixes address other aspects of the bugs. The `@tdd_expected_fail` tags are functionally correct and must remain until the specific scenario assertions pass: - `tdd_exec_env_resolution_precedence.feature` — bug #1080 (closed 2026-03-31). The precedence-level-2-vs-4 scenario still fails. - `session_list_summary_dedup.feature` — bug #3046 (closed 2026-04-05). The dedup-consistency scenarios still fail. - `actor_add_update_enforcement.feature` — bug #2609 (closed 2026-04-05). The enforcement scenarios still fail. - `ci_workflow_validation.feature:134` — #4227 (closed 2026-04-08). The CI YAML threshold assertion still fails. ## Verification - `grep -r "@skip" features/ --include="*.feature"` → **zero results** ✓ - `grep -n "tags=not @skip" noxfile.py` → **zero results** ✓ - `nox -s unit_tests` → **629 features passed, 0 failed** ✓ (up from ~545 before this PR) - CI all green (coverage ≥ 97%) ✓ - Integration tests (Robot Framework) do not use `@skip` — confirmed no action needed ✓ - E2E tests (Robot Framework) do not use `@skip` — confirmed no action needed ✓ - `CHANGELOG.md` updated with entry for this change ✓ - `CONTRIBUTORS.md` — Rui Hu already listed ✓ ## Issues Addressed Closes #7025 Co-authored-by: CleverThis <hal9000@cleverthis.com> Reviewed-on: #7221 Reviewed-by: HAL 9000 <HAL9000@cleverthis.com> Reviewed-by: HAL9001 <hal9001@cleverthis.com> Co-authored-by: Rui Hu <rui.hu@cleverthis.com> Co-committed-by: Rui Hu <rui.hu@cleverthis.com>
216 lines
11 KiB
Gherkin
216 lines
11 KiB
Gherkin
Feature: A2A JSON-RPC 2.0 wire format compliance
|
|
As a developer maintaining the A2A protocol layer
|
|
I want A2aRequest and A2aResponse to use JSON-RPC 2.0 field names
|
|
So that external A2A-compliant clients can communicate with the server
|
|
|
|
# -------------------------------------------------------------------
|
|
# A2aRequest serialisation — JSON-RPC 2.0 field names
|
|
# -------------------------------------------------------------------
|
|
|
|
Scenario: A2aRequest serialises with jsonrpc field set to "2.0"
|
|
Given a valid A2aRequest with method "_cleveragents/plan/status" and params {"plan_id": "P1"}
|
|
When I serialise the request to a dict
|
|
Then the serialised dict should contain key "jsonrpc" with value "2.0"
|
|
|
|
Scenario: A2aRequest serialises with id field
|
|
Given a valid A2aRequest with method "_cleveragents/plan/status" and params {"plan_id": "P1"}
|
|
When I serialise the request to a dict
|
|
Then the serialised dict should contain key "id"
|
|
|
|
Scenario: A2aRequest serialises with method field
|
|
Given a valid A2aRequest with method "_cleveragents/plan/status" and params {"plan_id": "P1"}
|
|
When I serialise the request to a dict
|
|
Then the serialised dict should contain key "method" with value "_cleveragents/plan/status"
|
|
|
|
Scenario: A2aRequest serialises with params field
|
|
Given a valid A2aRequest with method "_cleveragents/plan/status" and params {"plan_id": "P1"}
|
|
When I serialise the request to a dict
|
|
Then the serialised dict should contain key "params"
|
|
|
|
Scenario: A2aRequest does not contain non-standard field a2a_version
|
|
Given a valid A2aRequest with method "_cleveragents/plan/status" and params {"plan_id": "P1"}
|
|
When I serialise the request to a dict
|
|
Then the serialised dict should not contain key "a2a_version"
|
|
|
|
Scenario: A2aRequest does not contain non-standard field request_id
|
|
Given a valid A2aRequest with method "_cleveragents/plan/status" and params {"plan_id": "P1"}
|
|
When I serialise the request to a dict
|
|
Then the serialised dict should not contain key "request_id"
|
|
|
|
Scenario: A2aRequest does not contain non-standard field operation
|
|
Given a valid A2aRequest with method "_cleveragents/plan/status" and params {"plan_id": "P1"}
|
|
When I serialise the request to a dict
|
|
Then the serialised dict should not contain key "operation"
|
|
|
|
Scenario: A2aRequest does not contain non-standard field auth
|
|
Given a valid A2aRequest with method "_cleveragents/plan/status" and params {"plan_id": "P1"}
|
|
When I serialise the request to a dict
|
|
Then the serialised dict should not contain key "auth"
|
|
|
|
Scenario: A2aRequest auto-generates id when not provided
|
|
Given a valid A2aRequest with method "session.create" and params {}
|
|
Then the request id should be non-empty
|
|
|
|
Scenario: A2aRequest accepts explicit id
|
|
Given an A2aRequest with method "session.create" and id "my-custom-id"
|
|
Then the request id should equal "my-custom-id"
|
|
|
|
Scenario: A2aRequest rejects empty method
|
|
When I try to create an A2aRequest with empty method
|
|
Then a wire format ValidationError should be raised
|
|
|
|
Scenario: A2aRequest rejects non-2.0 jsonrpc version
|
|
When I try to create an A2aRequest with jsonrpc "1.0"
|
|
Then a wire format ValidationError should be raised
|
|
|
|
# -------------------------------------------------------------------
|
|
# A2aResponse serialisation — JSON-RPC 2.0 field names (success)
|
|
# -------------------------------------------------------------------
|
|
|
|
Scenario: A2aResponse success serialises with jsonrpc field set to "2.0"
|
|
Given a successful A2aResponse with id "REQ-001" and result {"status": "ok"}
|
|
When I serialise the response to a dict
|
|
Then the serialised dict should contain key "jsonrpc" with value "2.0"
|
|
|
|
Scenario: A2aResponse success serialises with id field
|
|
Given a successful A2aResponse with id "REQ-001" and result {"status": "ok"}
|
|
When I serialise the response to a dict
|
|
Then the serialised dict should contain key "id" with value "REQ-001"
|
|
|
|
Scenario: A2aResponse success serialises with result field
|
|
Given a successful A2aResponse with id "REQ-001" and result {"status": "ok"}
|
|
When I serialise the response to a dict
|
|
Then the serialised dict should contain key "result"
|
|
|
|
Scenario: A2aResponse success does not contain non-standard field a2a_version
|
|
Given a successful A2aResponse with id "REQ-001" and result {"status": "ok"}
|
|
When I serialise the response to a dict
|
|
Then the serialised dict should not contain key "a2a_version"
|
|
|
|
Scenario: A2aResponse success does not contain non-standard field request_id
|
|
Given a successful A2aResponse with id "REQ-001" and result {"status": "ok"}
|
|
When I serialise the response to a dict
|
|
Then the serialised dict should not contain key "request_id"
|
|
|
|
Scenario: A2aResponse success does not contain non-standard field status
|
|
Given a successful A2aResponse with id "REQ-001" and result {"status": "ok"}
|
|
When I serialise the response to a dict
|
|
Then the serialised dict should not contain key "status"
|
|
|
|
Scenario: A2aResponse success does not contain non-standard field data
|
|
Given a successful A2aResponse with id "REQ-001" and result {"status": "ok"}
|
|
When I serialise the response to a dict
|
|
Then the serialised dict should not contain key "data"
|
|
|
|
Scenario: A2aResponse success does not contain non-standard field timing_ms
|
|
Given a successful A2aResponse with id "REQ-001" and result {"status": "ok"}
|
|
When I serialise the response to a dict
|
|
Then the serialised dict should not contain key "timing_ms"
|
|
|
|
# -------------------------------------------------------------------
|
|
# A2aResponse serialisation — JSON-RPC 2.0 field names (error)
|
|
# -------------------------------------------------------------------
|
|
|
|
Scenario: A2aResponse error serialises with error field
|
|
Given an error A2aResponse with id "REQ-002" and error code "NOT_FOUND"
|
|
When I serialise the response to a dict
|
|
Then the serialised dict should contain key "error"
|
|
|
|
Scenario: A2aResponse error does not contain result field
|
|
Given an error A2aResponse with id "REQ-002" and error code "NOT_FOUND"
|
|
When I serialise the response to a dict
|
|
Then the serialised dict should not contain key "result"
|
|
|
|
Scenario: A2aResponse error does not contain non-standard field status
|
|
Given an error A2aResponse with id "REQ-002" and error code "NOT_FOUND"
|
|
When I serialise the response to a dict
|
|
Then the serialised dict should not contain key "status"
|
|
|
|
# -------------------------------------------------------------------
|
|
# A2aResponse validation — mutual exclusion of result and error
|
|
# -------------------------------------------------------------------
|
|
|
|
Scenario: A2aResponse requires either result or error
|
|
When I try to create an A2aResponse with neither result nor error
|
|
Then a wire format ValidationError should be raised
|
|
|
|
Scenario: A2aResponse rejects both result and error set simultaneously
|
|
When I try to create an A2aResponse with both result and error
|
|
Then a wire format ValidationError should be raised
|
|
|
|
# -------------------------------------------------------------------
|
|
# Deserialisation — inbound JSON-RPC 2.0 payloads
|
|
# -------------------------------------------------------------------
|
|
|
|
Scenario: A2aRequest deserialises from JSON-RPC 2.0 compliant dict
|
|
Given a JSON-RPC 2.0 request dict with method "message/send" and id "42"
|
|
When I deserialise the dict into an A2aRequest
|
|
Then the request method should equal "message/send"
|
|
And the request id should equal "42"
|
|
And the request jsonrpc should equal "2.0"
|
|
|
|
Scenario: A2aResponse deserialises from JSON-RPC 2.0 success dict
|
|
Given a JSON-RPC 2.0 success response dict with id "42" and result {"plan_id": "P1"}
|
|
When I deserialise the dict into an A2aResponse
|
|
Then the response result should contain key "plan_id"
|
|
And the response error should be None
|
|
|
|
Scenario: A2aResponse deserialises from JSON-RPC 2.0 error dict
|
|
Given a JSON-RPC 2.0 error response dict with id "42" and error code "NOT_FOUND"
|
|
When I deserialise the dict into an A2aResponse
|
|
Then the response error should not be None
|
|
And the response result should be None
|
|
|
|
# -------------------------------------------------------------------
|
|
# Facade dispatch — produces JSON-RPC 2.0 compliant responses
|
|
# -------------------------------------------------------------------
|
|
|
|
Scenario: Facade dispatch produces response with jsonrpc "2.0"
|
|
Given a wire-format facade with no services
|
|
When I dispatch wire-format method "_cleveragents/health/check" with params {}
|
|
Then the wire-format response jsonrpc should equal "2.0"
|
|
|
|
Scenario: Facade dispatch success produces response with result field
|
|
Given a wire-format facade with no services
|
|
When I dispatch wire-format method "_cleveragents/health/check" with params {}
|
|
Then the wire-format response result should not be None
|
|
|
|
Scenario: Facade dispatch success produces response without error field
|
|
Given a wire-format facade with no services
|
|
When I dispatch wire-format method "_cleveragents/health/check" with params {}
|
|
Then the wire-format response error should be None
|
|
|
|
Scenario: Facade dispatch error produces response with error field
|
|
Given a wire-format facade with no services
|
|
When I dispatch wire-format method "unknown/method" with params {}
|
|
Then the wire-format response error should not be None
|
|
|
|
Scenario: Facade dispatch preserves request id in response
|
|
Given a wire-format facade with no services
|
|
When I dispatch wire-format method "_cleveragents/health/check" with id "test-id-123" and params {}
|
|
Then the wire-format response id should equal "test-id-123"
|
|
|
|
# -------------------------------------------------------------------
|
|
# A2aErrorDetail — JSON-RPC 2.0 field name compliance (issue #2745)
|
|
# -------------------------------------------------------------------
|
|
|
|
@tdd_issue @tdd_issue_4229 @tdd_expected_fail
|
|
Scenario: A2aErrorDetail serialises with data field not details
|
|
Given an A2aErrorDetail with code "NOT_FOUND" and message "gone" and data {"id": "x"}
|
|
When I serialise the error detail to a dict
|
|
Then the error detail dict should contain key "data"
|
|
And the error detail dict should not contain key "details"
|
|
|
|
@tdd_issue @tdd_issue_4229 @tdd_expected_fail
|
|
Scenario: A2aErrorDetail serialises with empty data by default
|
|
Given an A2aErrorDetail with code "ERR" and message "error" and no data
|
|
When I serialise the error detail to a dict
|
|
Then the error detail dict should contain key "data"
|
|
And the error detail dict should not contain key "details"
|
|
|
|
@tdd_issue @tdd_issue_4229 @tdd_expected_fail
|
|
Scenario: A2aErrorDetail data field preserves payload values
|
|
Given an A2aErrorDetail with code "NOT_FOUND" and message "gone" and data {"plan_id": "abc123"}
|
|
When I serialise the error detail to a dict
|
|
Then the error detail data should contain key "plan_id"
|