From 2005b8ef8285da7ed39f90aee9339c14c86ac9db Mon Sep 17 00:00:00 2001 From: Rui Hu Date: Mon, 13 Apr 2026 04:56:01 +0000 Subject: [PATCH] feat(tests): replace all @skip tags with proper @tdd_expected_fail tags or remove them across the entire codebase (#7221) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ## 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_` 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 Reviewed-on: https://git.cleverthis.com/cleveragents/cleveragents-core/pulls/7221 Reviewed-by: HAL 9000 Reviewed-by: HAL9001 Co-authored-by: Rui Hu Co-committed-by: Rui Hu --- CHANGELOG.md | 6 +++ features/a2a_jsonrpc_wire_format.feature | 9 ++-- features/actor_add_name_positional.feature | 6 +-- features/actor_add_rich_output.feature | 27 ++++-------- features/actor_add_update_enforcement.feature | 12 ++---- features/actor_cli_coverage.feature | 27 ++++-------- features/actor_cli_yaml.feature | 6 +-- .../actor_remove_impact_computation.feature | 6 +-- features/automation_profile_cli.feature | 3 +- features/checkpoint_auto_triggers.feature | 3 +- features/ci_workflow_validation.feature | 7 +++- features/cli_extensions.feature | 9 ++-- features/cli_global_format_flag.feature | 3 +- features/cli_json_envelope.feature | 6 +-- features/cli_output_formats.feature | 3 +- features/config_cli_coverage_boost.feature | 9 ++-- .../config_cli_safety_net_coverage.feature | 6 +-- features/config_project_scope.feature | 3 +- features/consolidated_config.feature | 3 +- features/consolidated_misc.feature | 3 +- features/consolidated_skill.feature | 3 +- features/container_tool_exec.feature | 15 +++---- features/context_cli_wiring.feature | 24 ++++------- features/coverage_threshold_config.feature | 3 +- .../coverage_threshold_enforcement.feature | 3 +- features/database_models_coverage_r2.feature | 12 ++---- ...database_models_lifecycle_coverage.feature | 3 +- features/database_models_new_coverage.feature | 6 +-- features/depth_breadth_projection.feature | 3 +- features/exec_env_project_override.feature | 12 ++---- features/m6_autonomy_acceptance.feature | 9 ++-- features/models_lifecycle_coverage_r2.feature | 6 +-- features/plan_cli_coverage_boost.feature | 3 +- features/plan_cli_spec_alignment.feature | 9 ++-- features/plan_diff_artifacts.feature | 6 +-- features/plan_explain.feature | 3 +- .../plan_namespaced_name_validation.feature | 9 ++-- features/plan_prompt_command.feature | 3 +- ...ject_context_set_exec_env_priority.feature | 18 +++----- features/project_create_persist.feature | 12 ++---- features/project_show_after_create.feature | 9 ++-- features/repo_indexing_cli.feature | 9 ++-- ...positories_error_handling_coverage.feature | 6 +-- features/resource_cli.feature | 3 +- features/resource_cli_coverage.feature | 3 +- .../resource_list_lifecycle_state.feature | 3 +- features/resource_type_bootstrap_fs.feature | 9 ++-- .../resource_type_bootstrap_fs_mount.feature | 18 +++----- features/resource_type_bootstrap_git.feature | 6 +-- .../security_template_coverage_boost.feature | 3 +- features/session_cli_coverage_boost.feature | 3 +- features/session_list_error.feature | 6 +-- features/session_list_summary_dedup.feature | 13 +----- features/skill_cli.feature | 12 ++---- features/tdd_a2a_sdk_dependency.feature | 12 ++---- ...dd_automation_profile_session_leak.feature | 27 ++++-------- ...udget_eviction_deletes_not_demotes.feature | 6 +-- features/tdd_checkpoint_real_rollback.feature | 9 ++-- ...incomplete_subcommand_registration.feature | 9 ++-- features/tdd_context_tier_runtime.feature | 12 ++---- .../tdd_correction_checkpoint_wiring.feature | 9 ++-- features/tdd_e2e_implicit_init.feature | 6 +-- .../tdd_event_bus_exception_swallow.feature | 6 +-- ...tdd_exec_env_resolution_precedence.feature | 20 +-------- ...tdd_indentation_library_try_except.feature | 21 ++++------ features/tdd_invariant_persistence.feature | 12 ++---- .../tdd_json_decode_crash_persistence.feature | 3 +- features/tdd_mcp_error_content_key.feature | 6 +-- ...missing_validation_unit_tests_yaml.feature | 3 +- .../tdd_plan_correct_auto_resolve.feature | 6 +-- .../tdd_regression_guards_exec_env.feature | 18 ++++++++ ...tdd_regression_guards_session_list.feature | 18 ++++++++ .../tdd_server_connect_atomic_writes.feature | 3 +- features/tdd_session_create_di.feature | 3 +- features/tdd_session_create_persist.feature | 3 +- features/tdd_skill_add_regression.feature | 9 +--- features/tdd_sqlite_url_cwd.feature | 6 +-- .../tdd_subplan_spawn_orchestration.feature | 9 ++-- .../tdd_tool_runner_env_precedence.feature | 39 ++++++----------- .../testing/tdd_expected_fail_demo.feature | 3 +- features/tls_certificate_check.feature | 42 +++++++------------ features/tool_wrapping_runtime.feature | 6 +-- features/tui_session_export_import.feature | 3 +- ...tui_slash_command_overlay_coverage.feature | 3 +- .../tui_slash_overlay_descriptions.feature | 9 ++-- noxfile.py | 4 -- 86 files changed, 275 insertions(+), 492 deletions(-) create mode 100644 features/tdd_regression_guards_exec_env.feature create mode 100644 features/tdd_regression_guards_session_list.feature diff --git a/CHANGELOG.md b/CHANGELOG.md index 89d67e2c3..35247aff4 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -7,6 +7,12 @@ The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/). ### Added +- **TDD Issue-Capture Test Activation** (#7025): Replaced 234 bare `@skip` tags + across 82 Behave feature files with the correct `@tdd_expected_fail @tdd_issue + @tdd_issue_` tag system. Scenarios whose referenced bugs were already fixed + had `@tdd_expected_fail` removed and now run as permanent regression guards. + Net result: 629 features active in CI (up from ~545), zero `@skip` tags remain. + - **Git Worktree Sandbox Apply** (#4454): The `plan apply` command now merges LLM-generated changes via `git merge` from an isolated worktree branch instead of flat `shutil.copy2`. Displays spec-aligned Apply Summary diff --git a/features/a2a_jsonrpc_wire_format.feature b/features/a2a_jsonrpc_wire_format.feature index d6ea522cf..9d2f3b963 100644 --- a/features/a2a_jsonrpc_wire_format.feature +++ b/features/a2a_jsonrpc_wire_format.feature @@ -194,24 +194,21 @@ Feature: A2A JSON-RPC 2.0 wire format compliance # A2aErrorDetail — JSON-RPC 2.0 field name compliance (issue #2745) # ------------------------------------------------------------------- -# @tdd_issue @tdd_issue_4229 @tdd_expected_fail @skip - @skip + @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 @skip - @skip + @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 @skip - @skip + @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 diff --git a/features/actor_add_name_positional.feature b/features/actor_add_name_positional.feature index 79a384d08..937d2147e 100644 --- a/features/actor_add_name_positional.feature +++ b/features/actor_add_name_positional.feature @@ -3,16 +3,14 @@ Feature: agents actor add NAME positional argument I want to pass the actor name as a positional argument to `agents actor add` So that the CLI matches the spec synopsis: agents actor add --config -# @tdd_issue @tdd_issue_4230 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4230 @tdd_expected_fail Scenario: actor add accepts NAME as positional argument Given an actor CLI runner And I have an actor JSON config file without a name field When I run actor add with NAME positional argument and config Then the actor add should succeed with the positional name -# @tdd_issue @tdd_issue_4230 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4230 @tdd_expected_fail Scenario: actor add NAME positional argument takes precedence over config name Given an actor CLI runner And I have an actor JSON config file with a different name diff --git a/features/actor_add_rich_output.feature b/features/actor_add_rich_output.feature index b86b933ab..949ce85b8 100644 --- a/features/actor_add_rich_output.feature +++ b/features/actor_add_rich_output.feature @@ -3,64 +3,55 @@ Feature: actor add rich output panels I want `agents actor add` to display all spec-required panels So that I can see the full details of a newly added actor -# @tdd_issue @tdd_issue_4231 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4231 @tdd_expected_fail Scenario: Actor Added panel includes Type field Given an actor add CLI runner with a typed config When I run actor add with the typed config Then the actor added panel should contain the Type field -# @tdd_issue @tdd_issue_4231 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4231 @tdd_expected_fail Scenario: Config panel is rendered after actor add Given an actor add CLI runner with a typed config When I run actor add with the typed config Then the output should contain a Config panel -# @tdd_issue @tdd_issue_4231 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4231 @tdd_expected_fail Scenario: Config panel shows Path, Hash, Options, Nodes, Edges Given an actor add CLI runner with a typed config When I run actor add with the typed config Then the Config panel should show Path Hash Options Nodes and Edges -# @tdd_issue @tdd_issue_4231 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4231 @tdd_expected_fail Scenario: Capabilities panel is rendered when capabilities are present Given an actor add CLI runner with capabilities in config When I run actor add with the capabilities config Then the output should contain a Capabilities panel with the capability list -# @tdd_issue @tdd_issue_4231 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4231 @tdd_expected_fail Scenario: Tools panel is rendered when tools are present Given an actor add CLI runner with tools in config When I run actor add with the tools config Then the output should contain a Tools panel with tool rows -# @tdd_issue @tdd_issue_4231 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4231 @tdd_expected_fail Scenario: Success status line is printed after all panels Given an actor add CLI runner with a typed config When I run actor add with the typed config Then the output should end with the actor added success line -# @tdd_issue @tdd_issue_4231 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4231 @tdd_expected_fail Scenario: No Capabilities panel when capabilities list is empty Given an actor add CLI runner with a typed config When I run actor add with the typed config Then the output should not contain a Capabilities panel -# @tdd_issue @tdd_issue_4231 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4231 @tdd_expected_fail Scenario: No Tools panel when tools list is empty Given an actor add CLI runner with a typed config When I run actor add with the typed config Then the output should not contain a Tools panel -# @tdd_issue @tdd_issue_4231 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4231 @tdd_expected_fail Scenario: Non-rich format skips all extra panels Given an actor add CLI runner with a typed config When I run actor add with the typed config in json format diff --git a/features/actor_add_update_enforcement.feature b/features/actor_add_update_enforcement.feature index 7dff0507d..f69eff613 100644 --- a/features/actor_add_update_enforcement.feature +++ b/features/actor_add_update_enforcement.feature @@ -5,8 +5,7 @@ Feature: agents actor add enforces --update flag for existing actors I want `agents actor add` to fail with a clear error when re-adding an existing actor So that I cannot accidentally overwrite actor configurations without explicit intent -# @tdd_issue @tdd_issue_2609 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_2609 @tdd_expected_fail @tdd_issue_4178 Scenario: Re-adding an existing actor without --update fails with error panel Given an actor add CLI runner where the actor already exists When I run actor add without the --update flag @@ -15,8 +14,7 @@ Feature: agents actor add enforces --update flag for existing actors And the actor-add-enforcement output should contain "Use --update to replace the existing actor definition" And the actor-add-enforcement output should contain the registration timestamp -# @tdd_issue @tdd_issue_2609 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_2609 @tdd_expected_fail @tdd_issue_4178 Scenario: Re-adding an existing actor without --update shows error status line Given an actor add CLI runner where the actor already exists When I run actor add without the --update flag @@ -24,16 +22,14 @@ Feature: agents actor add enforces --update flag for existing actors And the actor-add-enforcement output should contain "Actor already registered" And the actor-add-enforcement output should contain "use --update to replace" -# @tdd_issue @tdd_issue_2609 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_2609 @tdd_expected_fail @tdd_issue_4178 Scenario: Re-adding an existing actor with --update succeeds Given an actor add CLI runner where the actor already exists When I run actor add with the --update flag Then the actor-add-enforcement exit code should be 0 And the actor-add-enforcement output should contain "Actor updated" -# @tdd_issue @tdd_issue_2609 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_2609 @tdd_expected_fail @tdd_issue_4178 Scenario: Adding a new actor without --update succeeds Given an actor add CLI runner where the actor does not exist When I run actor add without the --update flag diff --git a/features/actor_cli_coverage.feature b/features/actor_cli_coverage.feature index 4d4726450..5080ec7fa 100644 --- a/features/actor_cli_coverage.feature +++ b/features/actor_cli_coverage.feature @@ -8,8 +8,7 @@ Feature: Actor CLI coverage When I run actor add without config Then the actor command should fail with bad parameter -# @tdd_issue @tdd_issue_4232 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4232 @tdd_expected_fail Scenario: Add actor with JSON config file Given an actor CLI runner And I have an actor JSON config file @@ -22,8 +21,7 @@ Feature: Actor CLI coverage When I run actor add with that config Then the actor command should fail with bad parameter -# @tdd_issue @tdd_issue_4232 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4232 @tdd_expected_fail Scenario: Add actor allows unsafe config when flag is provided Given an actor CLI runner And I have an unsafe actor JSON config file @@ -41,24 +39,21 @@ Feature: Actor CLI coverage When I run actor add with that config Then the actor command should fail with bad parameter -# @tdd_issue @tdd_issue_4232 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4232 @tdd_expected_fail Scenario: Add actor falls back to YAML-only config Given an actor CLI runner And I have an actor YAML-only config file When I run actor add with that config Then the actor add should pass the loaded config -# @tdd_issue @tdd_issue_4232 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4232 @tdd_expected_fail Scenario: Add actor uses service path with graph descriptor Given an actor CLI runner And I have an actor graph config file When I run actor add via service with that config Then the service actor add should include graph descriptor -# @tdd_issue @tdd_issue_4232 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4232 @tdd_expected_fail Scenario: Add actor merges CLI options into config blob Given an actor CLI runner And I have an actor JSON config file @@ -71,8 +66,7 @@ Feature: Actor CLI coverage When I run actor add with that config Then the actor command should fail with bad parameter -# @tdd_issue @tdd_issue_4232 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4232 @tdd_expected_fail Scenario: Add actor aborts on business rule violation Given an actor CLI runner When I run actor add with business rule violation @@ -163,8 +157,7 @@ Feature: Actor CLI coverage When I run set-default actor with violation Then the actor command should abort with error -# @tdd_issue @tdd_issue_4232 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4232 @tdd_expected_fail Scenario: Add actor merges options and parses boolean override Given an actor CLI runner And I have an actor JSON config file with options @@ -183,8 +176,7 @@ Feature: Actor CLI coverage When I run actor add with empty option key Then the actor command should fail with bad parameter -# @tdd_issue @tdd_issue_4232 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4232 @tdd_expected_fail Scenario: Add actor via service rejects unsafe canonical config Given an actor CLI runner And I have an actor JSON config file @@ -218,8 +210,7 @@ Feature: Actor CLI coverage When I run actor remove via service path Then the actor service remove should be called -# @tdd_issue @tdd_issue_4232 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4232 @tdd_expected_fail Scenario: Add actor parses uppercase boolean option override Given an actor CLI runner And I have an actor JSON config file with options diff --git a/features/actor_cli_yaml.feature b/features/actor_cli_yaml.feature index 36192eb68..d234906b2 100644 --- a/features/actor_cli_yaml.feature +++ b/features/actor_cli_yaml.feature @@ -40,16 +40,14 @@ Feature: Actor CLI YAML-first alignment Then the actor add should pass the loaded config And the output should say Actor updated -# @tdd_issue @tdd_issue_4233 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4233 @tdd_expected_fail Scenario: Actor add outputs JSON format Given an actor CLI runner And I have an actor JSON config file When I run actor add with format json Then the actor add output should contain JSON data -# @tdd_issue @tdd_issue_4233 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4233 @tdd_expected_fail Scenario: Actor add with YAML config file and format Given an actor CLI runner And I have an actor YAML-only config file diff --git a/features/actor_remove_impact_computation.feature b/features/actor_remove_impact_computation.feature index bb7a1085e..20609e0bc 100644 --- a/features/actor_remove_impact_computation.feature +++ b/features/actor_remove_impact_computation.feature @@ -6,8 +6,7 @@ Feature: agents actor remove Impact section shows real counts Background: Given an actor CLI runner -# @tdd_issue @tdd_issue_4234 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4234 @tdd_expected_fail Scenario: Impact panel shows non-zero counts when actor is referenced Given an actor "local/my-actor" referenced by 2 sessions, 1 active plan, and 3 actions When I run actor remove for "local/my-actor" @@ -16,8 +15,7 @@ Feature: agents actor remove Impact section shows real counts And the Impact panel should show "1 affected" for Active Plans And the Impact panel should show "3" for Actions Referencing -# @tdd_issue @tdd_issue_4234 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4234 @tdd_expected_fail Scenario: Impact panel shows zero counts when actor has no references Given an actor "local/unused-actor" with no references When I run actor remove for "local/unused-actor" diff --git a/features/automation_profile_cli.feature b/features/automation_profile_cli.feature index 38a28eaa9..ed081c27c 100644 --- a/features/automation_profile_cli.feature +++ b/features/automation_profile_cli.feature @@ -94,8 +94,7 @@ Feature: Automation Profile CLI commands And the automation-profile json output should contain "built_in" And the automation-profile json output should contain "select_tool" -# @tdd_issue @tdd_issue_4235 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4235 @tdd_expected_fail Scenario: List profiles JSON output has spec-required profiles wrapper with summary When I run automation-profile list with --format json Then the automation-profile list should succeed diff --git a/features/checkpoint_auto_triggers.feature b/features/checkpoint_auto_triggers.feature index 956ce680f..01293f9b7 100644 --- a/features/checkpoint_auto_triggers.feature +++ b/features/checkpoint_auto_triggers.feature @@ -60,8 +60,7 @@ Feature: Automatic checkpoint triggers during Execute phase # on_subplan_spawn trigger # ─────────────────────────────────────────────────────────── -# @tdd_issue @tdd_issue_4236 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4236 @tdd_expected_fail Scenario: on_subplan_spawn checkpoint created when a child plan is spawned Given a subplan execution service with a checkpoint service and parent_plan_id "01ARZ3NDEKTSV4RRFFQ69G5FA8" And a subplan "01ARZ3NDEKTSV4RRFFQ69G5FAA" is configured diff --git a/features/ci_workflow_validation.feature b/features/ci_workflow_validation.feature index 2155bec57..0e124184b 100644 --- a/features/ci_workflow_validation.feature +++ b/features/ci_workflow_validation.feature @@ -130,9 +130,12 @@ Feature: CI workflow validation And the job "status-check" should depend on "coverage" # --- Coverage threshold --- + # Note: #4227 is closed, but this specific scenario still fails because + # the CI YAML does not yet encode a 97% threshold as a machine-readable + # value that the step definition can assert. The other three #4227 + # scenarios (noxfile-level checks) were promoted to regression guards. -# @tdd_issue @tdd_issue_4227 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4227 @tdd_expected_fail Scenario: CI coverage threshold is 97% Given the CI workflow file at ".forgejo/workflows/ci.yml" When I parse the CI workflow YAML diff --git a/features/cli_extensions.feature b/features/cli_extensions.feature index a9347fb43..416ef999a 100644 --- a/features/cli_extensions.feature +++ b/features/cli_extensions.feature @@ -304,8 +304,7 @@ Feature: CLI extensions for plan and action commands # DEEP COVERAGE: Output snapshot assertions JSON/YAML/table (#326) # ========================================================================== -# @tdd_issue @tdd_issue_4360 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4360 @tdd_expected_fail Scenario: Plan status in JSON format contains required keys Given cli extensions plans exist with automation profile "trusted" When I run cli extensions plan status with format "json" @@ -320,8 +319,7 @@ Feature: CLI extensions for plan and action commands Then the cli extensions output contains yaml field "automation_profile" And the cli extensions output contains yaml field "namespaced_name" -# @tdd_issue @tdd_issue_4361 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4361 @tdd_expected_fail Scenario: Action show in JSON format contains all required keys Given a cli extensions action with estimation actor "openai/gpt-4" When I run cli extensions action show with format "json" @@ -337,8 +335,7 @@ Feature: CLI extensions for plan and action commands Then the cli extensions output contains yaml field "estimation_actor" And the cli extensions output contains yaml field "strategy_actor" -# @tdd_issue @tdd_issue_4362 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4362 @tdd_expected_fail Scenario: Action show in JSON includes invariants list when present Given a cli extensions action with invariants When I run cli extensions action show with format "json" diff --git a/features/cli_global_format_flag.feature b/features/cli_global_format_flag.feature index eddf75327..1bb764c4e 100644 --- a/features/cli_global_format_flag.feature +++ b/features/cli_global_format_flag.feature @@ -48,8 +48,7 @@ Feature: Global --format flag propagation to subcommands # Subtask 3: version, info, diagnostics read format from global ctx.obj # ----------------------------------------------------------------------- -# @tdd_issue @tdd_issue_4363 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4363 @tdd_expected_fail Scenario: version command reads format from global ctx.obj When I invoke the CLI with global args "--format json version" Then the global format command should succeed diff --git a/features/cli_json_envelope.feature b/features/cli_json_envelope.feature index 0d3c9ad71..19430f143 100644 --- a/features/cli_json_envelope.feature +++ b/features/cli_json_envelope.feature @@ -19,8 +19,7 @@ Feature: CLI JSON/YAML output envelope structure And the JSON envelope should contain field "timing" And the JSON envelope should contain field "messages" -# @tdd_issue @tdd_issue_4369 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4369 @tdd_expected_fail Scenario: YAML output includes all required envelope fields Given there are actions for format testing When I run action list with --format yaml @@ -60,8 +59,7 @@ Feature: CLI JSON/YAML output envelope structure When I run action list with --format json Then the JSON envelope data should contain actor records -# @tdd_issue @tdd_issue_4370 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4370 @tdd_expected_fail Scenario: YAML envelope data field contains actor list payload Given there are actions for format testing When I run action list with --format yaml diff --git a/features/cli_output_formats.feature b/features/cli_output_formats.feature index dbcfb975b..c8d2f1622 100644 --- a/features/cli_output_formats.feature +++ b/features/cli_output_formats.feature @@ -92,8 +92,7 @@ Feature: CLI output formats parity Then json_keys and yaml_keys should match # Direct formatting module tests -# @tdd_issue @tdd_issue_4364 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4364 @tdd_expected_fail Scenario: Format output handles all format types for dict When I call format_output with a dict and format json Then the format result should be valid JSON dict diff --git a/features/config_cli_coverage_boost.feature b/features/config_cli_coverage_boost.feature index 235261297..66f0977b5 100644 --- a/features/config_cli_coverage_boost.feature +++ b/features/config_cli_coverage_boost.feature @@ -69,8 +69,7 @@ Feature: Config CLI coverage boost # ── config_list --project with secret masking: line 410 ───────────── -# @tdd_issue @tdd_issue_4237 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4237 @tdd_expected_fail Scenario: config list --project masks secret keys by default Given the cfg-boost config file has project "secproj" secret override "provider.openai.api-key" as "sk-supersecret" When I invoke cfg-boost config list project "secproj" format "json" @@ -79,8 +78,7 @@ Feature: Config CLI coverage boost # ── config_list --project non-rich with Path fspath: line 430 ─────── -# @tdd_issue @tdd_issue_4237 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4237 @tdd_expected_fail Scenario: config list --project non-rich format serialises Path values Given the cfg-boost config file has project "pathproj" override "core.data-dir" as "/tmp/somepath" When I invoke cfg-boost config list project "pathproj" format "json" with path value @@ -98,8 +96,7 @@ Feature: Config CLI coverage boost # ── config_list all non-rich with Path fspath: line 501 ───────────── -# @tdd_issue @tdd_issue_4237 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4237 @tdd_expected_fail Scenario: config list non-rich format serialises Path objects in all-keys mode When I invoke cfg-boost config list format "json" with path value in resolve_all Then the cfg-boost CLI result should have succeeded diff --git a/features/config_cli_safety_net_coverage.feature b/features/config_cli_safety_net_coverage.feature index 0ef8da074..0a2ae7158 100644 --- a/features/config_cli_safety_net_coverage.feature +++ b/features/config_cli_safety_net_coverage.feature @@ -200,8 +200,7 @@ Feature: Config CLI safety-net coverage Then the safety-net get rich output should contain "Configuration Value" And the safety-net get rich output should contain "Resolution chain" -# @tdd_issue @tdd_issue_4238 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4238 @tdd_expected_fail Scenario: safety-net config get yaml format produces valid YAML Given a safety-net isolated temp config directory When the safety-net CLI gets key "core.log.level" with format "yaml" @@ -217,8 +216,7 @@ Feature: Config CLI safety-net coverage # config_list - YAML and plain formats (L426-431) # ===================================================================== -# @tdd_issue @tdd_issue_4238 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4238 @tdd_expected_fail Scenario: safety-net config list yaml format produces valid YAML Given a safety-net isolated temp config directory When the safety-net CLI lists config with format "yaml" diff --git a/features/config_project_scope.feature b/features/config_project_scope.feature index 21212f943..8045848bf 100644 --- a/features/config_project_scope.feature +++ b/features/config_project_scope.feature @@ -41,8 +41,7 @@ Feature: Project-scoped configuration overrides When I run config get "core.automation-profile" with project "my-project" via CLI Then the CLI config get should succeed -# @tdd_issue @tdd_issue_4239 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4239 @tdd_expected_fail Scenario: Project list via CLI command shows only overrides Given a project-scoped config value "core.automation-profile" = "trusted" for project "cli-proj" And a project-scoped config value "plan.concurrency" = "16" for project "cli-proj" diff --git a/features/consolidated_config.feature b/features/consolidated_config.feature index a9f9dc4bd..f0547f125 100644 --- a/features/consolidated_config.feature +++ b/features/consolidated_config.feature @@ -628,8 +628,7 @@ Feature: Consolidated Config And the coverage branch tracking should be enabled -# @tdd_issue @tdd_issue_4227 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4227 Scenario: Coverage threshold is at least 97 percent in noxfile Given the noxfile py is loaded for coverage check Then the noxfile should contain a fail-under threshold of at least 97 diff --git a/features/consolidated_misc.feature b/features/consolidated_misc.feature index 79ba2e11d..3222b921c 100644 --- a/features/consolidated_misc.feature +++ b/features/consolidated_misc.feature @@ -449,8 +449,7 @@ Feature: Consolidated Misc @coverage -# @tdd_issue @tdd_issue_4240 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4240 @tdd_expected_fail Scenario: Test CLI main function pass statement When I call the CLI main function with no commands Then the function should complete without error diff --git a/features/consolidated_skill.feature b/features/consolidated_skill.feature index c90e9f956..1bb8e3b40 100644 --- a/features/consolidated_skill.feature +++ b/features/consolidated_skill.feature @@ -142,8 +142,7 @@ Feature: Consolidated Skill # ---- SkillRegistry Validation ---- -# @tdd_issue @tdd_issue_4241 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4241 @tdd_expected_fail Scenario: SkillRegistry validate_skill detects missing tools When I create a skill_registry with a mock tool registry And I validate a skill with missing tool refs diff --git a/features/container_tool_exec.feature b/features/container_tool_exec.feature index 54e85ddb8..323fa976d 100644 --- a/features/container_tool_exec.feature +++ b/features/container_tool_exec.feature @@ -123,16 +123,14 @@ Feature: Container-aware tool execution and I/O forwarding # -- ToolRunner container routing --------------------------------------- -# @tdd_issue @tdd_issue_4243 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4243 @tdd_expected_fail Scenario: ToolRunner delegates to ContainerToolExecutor when env is CONTAINER Given I have a ToolRunner with a ContainerToolExecutor mock When I execute a tool with container execution environment Then the ContainerToolExecutor should have been called And the resolver should have been called with the correct arguments -# @tdd_issue @tdd_issue_4243 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4243 @tdd_expected_fail Scenario: ToolRunner returns error when container executor is not configured Given I have a ToolRunner without a ContainerToolExecutor When I execute a tool with container execution environment @@ -452,15 +450,13 @@ Feature: Container-aware tool execution and I/O forwarding # ToolRunner container routing — additional edge cases # ========================================================================= -# @tdd_issue @tdd_issue_4243 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4243 @tdd_expected_fail Scenario: ToolRunner returns error when container env resolver raises ContainerUnavailableError Given I have a ToolRunner with an unavailable-container resolver When I execute a tool through the unavailable-container runner Then the tool result should indicate container unavailable -# @tdd_issue @tdd_issue_4243 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4243 @tdd_expected_fail Scenario: ToolRunner validates missing required input fields for container tools Given I have a ToolRunner with a container executor and required-field tool When I execute the container tool with missing required fields @@ -471,8 +467,7 @@ Feature: Container-aware tool execution and I/O forwarding When I execute a container tool with non-serialisable inputs Then the container tool result error should mention "not JSON-serialisable" -# @tdd_issue @tdd_issue_4243 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4243 @tdd_expected_fail Scenario: ToolRunner catches container executor exception Given I have a ToolRunner with a failing container executor When I execute a tool through the failing container runner diff --git a/features/context_cli_wiring.feature b/features/context_cli_wiring.feature index be2541253..d56df3303 100644 --- a/features/context_cli_wiring.feature +++ b/features/context_cli_wiring.feature @@ -75,8 +75,7 @@ Feature: Context CLI ACMS pipeline wiring (B2.cli) # ── context show with ACMS config ────────────────────────── -# @tdd_issue @tdd_issue_4244 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4244 @tdd_expected_fail Scenario: Show displays ACMS pipeline config Given I have set ACMS config on "local/wire-app" with hot-max-tokens 6000 When I run wired context show on "local/wire-app" with format "json" @@ -84,8 +83,7 @@ Feature: Context CLI ACMS pipeline wiring (B2.cli) And the wired output should be valid JSON And the wired JSON output should contain key "acms_config" -# @tdd_issue @tdd_issue_4244 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4244 @tdd_expected_fail Scenario: Show with view displays ACMS config Given I have set ACMS config on "local/wire-app" with hot-max-tokens 6000 When I run wired context show on "local/wire-app" with view "default" and format "json" @@ -99,8 +97,7 @@ Feature: Context CLI ACMS pipeline wiring (B2.cli) When I run wired inspect for project "local/wire-app" using defaults Then the wired context inspect command should succeed -# @tdd_issue @tdd_issue_4244 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4244 @tdd_expected_fail Scenario: Inspect with JSON format returns valid JSON When I run wired inspect for project "local/wire-app" using format "json" Then the wired context inspect command should succeed @@ -109,8 +106,7 @@ Feature: Context CLI ACMS pipeline wiring (B2.cli) And the wired JSON output should contain key "project_fragments" And the wired JSON output should contain key "actor_visibility" -# @tdd_issue @tdd_issue_4244 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4244 @tdd_expected_fail Scenario: Inspect with pre-populated fragments shows counts Given the tier service has a hot fragment "frag-1" for project "local/wire-app" And the tier service has a warm fragment "frag-2" for project "local/wire-app" @@ -118,8 +114,7 @@ Feature: Context CLI ACMS pipeline wiring (B2.cli) Then the wired context inspect command should succeed And the wired JSON project_fragments total should be 2 -# @tdd_issue @tdd_issue_4244 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4244 @tdd_expected_fail Scenario: Inspect shows project-scoped tier metrics not global counts Given the tier service has a hot fragment "scoped-a" for project "local/wire-app" And the tier service has a hot fragment "other-b" for project "local/other-proj" @@ -141,8 +136,7 @@ Feature: Context CLI ACMS pipeline wiring (B2.cli) When I run wired simulate for project "local/wire-app" using defaults Then the wired context simulate command should succeed -# @tdd_issue @tdd_issue_4244 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4244 @tdd_expected_fail Scenario: Simulate with JSON format returns valid JSON When I run wired simulate for project "local/wire-app" using format "json" Then the wired context simulate command should succeed @@ -156,8 +150,7 @@ Feature: Context CLI ACMS pipeline wiring (B2.cli) When I run wired simulate for project "local/wire-app" using budget 2000 Then the wired context simulate command should succeed -# @tdd_issue @tdd_issue_4244 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4244 @tdd_expected_fail Scenario: Simulate with pre-populated fragments assembles them Given the tier service has a hot fragment "sim-1" for project "local/wire-app" sized at 100 tokens When I run wired simulate for project "local/wire-app" using format "json" @@ -176,8 +169,7 @@ Feature: Context CLI ACMS pipeline wiring (B2.cli) When I run wired simulate for project "local/wire-app" using strategy "breadth_first" Then the wired context simulate command should succeed -# @tdd_issue @tdd_issue_4244 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4244 @tdd_expected_fail Scenario: Simulate with focus filters fragments by resource URI Given a focused hot fragment "foc-1" with resource "uko:file/main.py" and 100 tokens exists for project "local/wire-app" And a focused hot fragment "foc-2" with resource "uko:file/test.py" and 80 tokens exists for project "local/wire-app" diff --git a/features/coverage_threshold_config.feature b/features/coverage_threshold_config.feature index f286b9a03..1514ef0f0 100644 --- a/features/coverage_threshold_config.feature +++ b/features/coverage_threshold_config.feature @@ -40,8 +40,7 @@ Feature: Coverage threshold configuration Given the noxfile py is loaded for coverage check Then the noxfile should define a coverage_report session -# @tdd_issue @tdd_issue_4227 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4227 Scenario: Noxfile enforces fail-under threshold of at least 97 Given the noxfile py is loaded for coverage check Then the noxfile should contain a fail-under threshold of at least 97 diff --git a/features/coverage_threshold_enforcement.feature b/features/coverage_threshold_enforcement.feature index 37e138cf9..33732eee1 100644 --- a/features/coverage_threshold_enforcement.feature +++ b/features/coverage_threshold_enforcement.feature @@ -3,8 +3,7 @@ Feature: Coverage threshold enforcement This feature validates that the coverage configuration and nox session are properly set up to enforce this requirement. -# @tdd_issue @tdd_issue_4227 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4227 Scenario: Coverage threshold is configured at 97% in noxfile Given the noxfile.py exists When I parse the COVERAGE_THRESHOLD constant from noxfile.py diff --git a/features/database_models_coverage_r2.feature b/features/database_models_coverage_r2.feature index 8426d8db5..227257a26 100644 --- a/features/database_models_coverage_r2.feature +++ b/features/database_models_coverage_r2.feature @@ -30,8 +30,7 @@ Feature: Database models coverage round 2 # LifecyclePlanModel — string processing_state (line 882) # --------------------------------------------------------------- -# @tdd_issue @tdd_issue_4245 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4245 @tdd_expected_fail Scenario: LifecyclePlanModel from_domain with string processing_state Given a Plan domain object whose processing_state is a plain string When I convert the plan to a model via from_domain @@ -41,8 +40,7 @@ Feature: Database models coverage round 2 # LifecyclePlanModel — automation_profile serialization (line 890) # --------------------------------------------------------------- -# @tdd_issue @tdd_issue_4245 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4245 @tdd_expected_fail Scenario: LifecyclePlanModel from_domain serializes automation_profile Given a Plan domain object with a non-null automation_profile When I convert the plan to a model via from_domain @@ -52,8 +50,7 @@ Feature: Database models coverage round 2 # LifecyclePlanModel — fallback namespace (line 906) # --------------------------------------------------------------- -# @tdd_issue @tdd_issue_4245 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4245 @tdd_expected_fail Scenario: LifecyclePlanModel from_domain falls back to local when namespace missing Given a Plan domain object whose namespaced_name has no namespace attribute When I convert the plan to a model via from_domain @@ -63,8 +60,7 @@ Feature: Database models coverage round 2 # LifecyclePlanModel — error_details serialization (line 923) # --------------------------------------------------------------- -# @tdd_issue @tdd_issue_4245 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4245 @tdd_expected_fail Scenario: LifecyclePlanModel from_domain serializes error_details Given a Plan domain object with non-null error_details When I convert the plan to a model via from_domain diff --git a/features/database_models_lifecycle_coverage.feature b/features/database_models_lifecycle_coverage.feature index b1e511356..5b25cade6 100644 --- a/features/database_models_lifecycle_coverage.feature +++ b/features/database_models_lifecycle_coverage.feature @@ -132,8 +132,7 @@ Feature: Lifecycle Data Persistence and Retrieval And the stored plan record phase should be "strategize" @lifecycle_plan @from_domain -# @tdd_issue @tdd_issue_4246 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4246 @tdd_expected_fail Scenario: A plan with no explicit state defaults to queued Given a plan domain object is prepared with neither action nor processing state When the stateless plan domain object is stored as a database record diff --git a/features/database_models_new_coverage.feature b/features/database_models_new_coverage.feature index bbd3aff52..653c55c0b 100644 --- a/features/database_models_new_coverage.feature +++ b/features/database_models_new_coverage.feature @@ -71,8 +71,7 @@ Feature: Database models new coverage for missed lines and branches # ------------------------------------------------------------------- @plan @from_domain @arguments_order_missing_key -# @tdd_issue @tdd_issue_4247 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4247 @tdd_expected_fail Scenario: Plan from_domain skips arguments_order entries not in arguments_dict Given a plan domain object with arguments_order containing a missing key When I convert the plan domain object to a database model @@ -80,8 +79,7 @@ Feature: Database models new coverage for missed lines and branches And the missing key should not appear in the argument child records @plan @from_domain @arguments_order_mixed -# @tdd_issue @tdd_issue_4247 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4247 @tdd_expected_fail Scenario: Plan from_domain handles mix of present and missing argument keys Given a plan domain object with three ordered keys but only two in arguments_dict When I convert the mixed-arguments plan to a database model diff --git a/features/depth_breadth_projection.feature b/features/depth_breadth_projection.feature index 38477e88c..8bec9a551 100644 --- a/features/depth_breadth_projection.feature +++ b/features/depth_breadth_projection.feature @@ -217,8 +217,7 @@ Feature: Depth/Breadth Projection System and Skeleton Context Propagation And all child skeleton fragments should have detail depth at most 1 And a child skeleton fragment should contain "[MODULE_GRAPH]: symbols=main" -# @inheritance @skeleton @tdd_issue @tdd_issue_4198 @tdd_expected_fail @skip - @skip + @inheritance @skeleton @tdd_issue @tdd_issue_4198 @tdd_expected_fail Scenario: PlanContextInheritance prioritises fragments near the child focus Given the depth/breadth projection modules are available And a parent assembled context with the following inheritance fragments: diff --git a/features/exec_env_project_override.feature b/features/exec_env_project_override.feature index 3a9521c41..356e5c39b 100644 --- a/features/exec_env_project_override.feature +++ b/features/exec_env_project_override.feature @@ -6,8 +6,7 @@ Feature: Execution environment project-level override reaches resolver Issue #1080: execution environment resolution does not honour project-level override (precedence level 2). -# @tdd_issue @tdd_issue_4248 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4248 @tdd_expected_fail Scenario: ToolCallRouter forwards project_env to resolver Given ee1080- a tool registry with a registered echo tool And ee1080- a tool runner and resolver spy @@ -15,8 +14,7 @@ Feature: Execution environment project-level override reaches resolver When ee1080- I route a tool call through the router Then ee1080- the resolver should have received project_env "container" -# @tdd_issue @tdd_issue_4248 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4248 @tdd_expected_fail Scenario: ToolCallRouter forwards plan_env to resolver Given ee1080- a tool registry with a registered echo tool And ee1080- a tool runner and resolver spy @@ -24,8 +22,7 @@ Feature: Execution environment project-level override reaches resolver When ee1080- I route a tool call through the router Then ee1080- the resolver should have received plan_env "host" -# @tdd_issue @tdd_issue_4248 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4248 @tdd_expected_fail Scenario: ToolCallRouter forwards both plan_env and project_env Given ee1080- a tool registry with a registered echo tool And ee1080- a tool runner and resolver spy @@ -34,8 +31,7 @@ Feature: Execution environment project-level override reaches resolver Then ee1080- the resolver should have received plan_env "host" And ee1080- the resolver should have received project_env "container" -# @tdd_issue @tdd_issue_4248 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4248 @tdd_expected_fail Scenario: ToolCallRouter without env params passes None to resolver Given ee1080- a tool registry with a registered echo tool And ee1080- a tool runner and resolver spy diff --git a/features/m6_autonomy_acceptance.feature b/features/m6_autonomy_acceptance.feature index bde51239a..10027590c 100644 --- a/features/m6_autonomy_acceptance.feature +++ b/features/m6_autonomy_acceptance.feature @@ -162,20 +162,17 @@ Feature: M6 autonomy acceptance smoke tests # --- A2A version negotiation --- -# @tdd_issue @tdd_issue_4249 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4249 @tdd_expected_fail Scenario: M6 smoke A2A version negotiation accepts 1.0 When I m6 smoke negotiate A2A version "1.0" Then the m6 smoke negotiated version should be "1.0" -# @tdd_issue @tdd_issue_4365 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4365 @tdd_expected_fail Scenario: M6 smoke A2A version negotiation rejects unsupported When I m6 smoke negotiate A2A version "2.0" Then the m6 smoke facade should raise A2aVersionMismatchError -# @tdd_issue @tdd_issue_4249 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4249 @tdd_expected_fail Scenario: M6 smoke A2A version is_supported returns correct result When I m6 smoke check if version "1.0" is supported Then the m6 smoke version support should be true diff --git a/features/models_lifecycle_coverage_r2.feature b/features/models_lifecycle_coverage_r2.feature index d3206a253..3f27baaf0 100644 --- a/features/models_lifecycle_coverage_r2.feature +++ b/features/models_lifecycle_coverage_r2.feature @@ -36,8 +36,7 @@ Feature: LifecycleAction and LifecyclePlan model branch coverage (round 2) # None project_links_rel/invariants_rel/arguments_rel # =================================================================== -# @tdd_issue @tdd_issue_4250 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4250 @tdd_expected_fail Scenario: r2mod- PlanModel.to_domain with all optional fields None Given a r2mod-PlanModel with all optional fields set to None When I r2mod-convert the PlanModel to domain @@ -52,8 +51,7 @@ Feature: LifecycleAction and LifecyclePlan model branch coverage (round 2) When I r2mod-attempt to convert the PlanModel to domain Then a r2mod-ValidationError should have been raised with "action_name" -# @tdd_issue @tdd_issue_4250 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4250 @tdd_expected_fail Scenario: r2mod- PlanModel.to_domain with argument having None value_json Given a r2mod-PlanModel with an argument having None value_json When I r2mod-convert the PlanModel to domain diff --git a/features/plan_cli_coverage_boost.feature b/features/plan_cli_coverage_boost.feature index 93e9332db..1fbd50641 100644 --- a/features/plan_cli_coverage_boost.feature +++ b/features/plan_cli_coverage_boost.feature @@ -64,8 +64,7 @@ Feature: Plan CLI coverage boost And the plan coverage output should contain "command" And the plan coverage output should contain "exit_code" -# @tdd_issue @tdd_issue_4251 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4251 @tdd_expected_fail Scenario: execute_plan JSON output has spec-required envelope structure Given a plan lifecycle CLI runner for coverage And a mocked lifecycle service for plan coverage commands diff --git a/features/plan_cli_spec_alignment.feature b/features/plan_cli_spec_alignment.feature index 8a357b60d..a2bf1cbeb 100644 --- a/features/plan_cli_spec_alignment.feature +++ b/features/plan_cli_spec_alignment.feature @@ -118,16 +118,14 @@ Feature: Plan CLI spec alignment And the plan spec cancel output should contain "Requirements changed" # ---- plan list: required column rendering ---- -# @tdd_issue @tdd_issue_4252 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4252 @tdd_expected_fail Scenario: Plan list rich output includes Name column Given plan spec alignment plans exist When I run plan list with no filters Then the plan spec list should succeed And the plan spec list output should contain "Name" -# @tdd_issue @tdd_issue_4252 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4252 @tdd_expected_fail Scenario: Plan list rich output includes Updated column Given plan spec alignment plans exist When I run plan list with no filters @@ -135,8 +133,7 @@ Feature: Plan CLI spec alignment And the plan spec list output should contain "Updat" And the plan spec list output should contain the current year-month timestamp -# @tdd_issue @tdd_issue_4252 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4252 @tdd_expected_fail Scenario: Plan list rich output includes Invariants column Given plan spec alignment plans exist When I run plan list with no filters diff --git a/features/plan_diff_artifacts.feature b/features/plan_diff_artifacts.feature index 5c299ac7c..d0df81ec6 100644 --- a/features/plan_diff_artifacts.feature +++ b/features/plan_diff_artifacts.feature @@ -54,8 +54,7 @@ Feature: Plan Diff and Artifacts Output And the artifacts should contain sandbox refs And the artifacts should contain files changed list -# @tdd_issue @tdd_issue_4253 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4253 @tdd_expected_fail Scenario: Plan artifacts shows validation results when available Given a plan with a changeset and validation summary When I request the artifacts in JSON format @@ -129,8 +128,7 @@ Feature: Plan Diff and Artifacts Output # Coverage: artifacts with apply summary metadata (line 181) -# @tdd_issue @tdd_issue_4253 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4253 @tdd_expected_fail Scenario: Artifacts include apply summary from metadata Given a plan with a changeset and apply summary metadata When I request the artifacts in JSON format diff --git a/features/plan_explain.feature b/features/plan_explain.feature index b3b637e5d..1332eb511 100644 --- a/features/plan_explain.feature +++ b/features/plan_explain.feature @@ -107,8 +107,7 @@ Feature: Plan explain and decision tree CLI commands # plan tree - json format # ------------------------------------------------------------------ -# @tdd_issue @tdd_issue_4254 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4254 @tdd_expected_fail Scenario: Tree with json format Given a set of test decisions forming a tree When I format the tree as json diff --git a/features/plan_namespaced_name_validation.feature b/features/plan_namespaced_name_validation.feature index e8632fe99..8af83ee88 100644 --- a/features/plan_namespaced_name_validation.feature +++ b/features/plan_namespaced_name_validation.feature @@ -6,22 +6,19 @@ Feature: NamespacedName validation # TDD for issue #2145/#2147: Names must start with a letter # --------------------------------------------------------------- -# @tdd_issue @tdd_issue_2145 @tdd_issue_2147 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_2145 @tdd_issue_2147 @tdd_expected_fail Scenario: NamespacedName.parse() rejects namespace starting with a digit When I parse the namespaced name "123abc/my-action" expecting an error Then a ValueError should be raised And the error message should contain "must start with a letter" -# @tdd_issue @tdd_issue_2145 @tdd_issue_2147 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_2145 @tdd_issue_2147 @tdd_expected_fail Scenario: NamespacedName constructor rejects name starting with a digit When I construct a NamespacedName with namespace "local" and name "123-action" expecting an error Then a ValidationError should be raised And the error message should contain "must start with a letter" -# @tdd_issue @tdd_issue_2145 @tdd_issue_2147 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_2145 @tdd_issue_2147 @tdd_expected_fail Scenario: NamespacedName constructor rejects namespace starting with a digit When I construct a NamespacedName with namespace "999org" and name "valid-name" expecting an error Then a ValidationError should be raised diff --git a/features/plan_prompt_command.feature b/features/plan_prompt_command.feature index b67d2cab5..3bce89e63 100644 --- a/features/plan_prompt_command.feature +++ b/features/plan_prompt_command.feature @@ -7,8 +7,7 @@ Feature: Plan prompt command When I run plan command help Then help output should include plan prompt command -# @tdd_issue @tdd_issue_4255 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4255 @tdd_expected_fail Scenario: Plan prompt delivers guidance and returns spec envelope in json Given a mocked lifecycle service prompt response When I run plan prompt with plan id "01HXM8C2ZK4Q7C2B3F2R4VYV6J" and guidance "Use mocks for database tests" in format "json" diff --git a/features/project_context_set_exec_env_priority.feature b/features/project_context_set_exec_env_priority.feature index adf3341e5..5aa462e62 100644 --- a/features/project_context_set_exec_env_priority.feature +++ b/features/project_context_set_exec_env_priority.feature @@ -10,42 +10,36 @@ Feature: Project context set --execution-env-priority flag (Bug #1079) Given a bug 1079 in-memory database is initialized And a project "local/bug1079-app" exists for bug 1079 -# @tdd_issue @tdd_issue_1079 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_1079 @tdd_issue_4178 Scenario: Bug #1079 - project context set accepts --execution-env-priority override When I run bug 1079 context set on "local/bug1079-app" with execution_environment "host" and execution_env_priority "override" Then the bug 1079 command should succeed And the stored bug 1079 execution_env_priority should be "override" -# @tdd_issue @tdd_issue_1079 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_1079 @tdd_issue_4178 Scenario: Bug #1079 - project context set accepts --execution-env-priority fallback When I run bug 1079 context set on "local/bug1079-app" with execution_environment "host" and execution_env_priority "fallback" Then the bug 1079 command should succeed And the stored bug 1079 execution_env_priority should be "fallback" -# @tdd_issue @tdd_issue_1079 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_1079 @tdd_issue_4178 Scenario: Bug #1079 - project context set rejects --execution-env-priority without --execution-environment When I run bug 1079 context set on "local/bug1079-app" with execution_env_priority "override" but no execution_environment Then the bug 1079 command should fail And the bug 1079 output should contain "--execution-env-priority requires --execution-environment" -# @tdd_issue @tdd_issue_1079 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_1079 @tdd_issue_4178 Scenario: Bug #1079 - project context set defaults execution-env-priority to fallback when not specified When I run bug 1079 context set on "local/bug1079-app" with execution_environment "host" but no execution_env_priority Then the bug 1079 command should succeed And the stored bug 1079 execution_env_priority should be "fallback" -# @tdd_issue @tdd_issue_1079 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_1079 @tdd_issue_4178 Scenario: Bug #1079 - project context set rejects invalid --execution-env-priority value When I run bug 1079 context set on "local/bug1079-app" with execution_environment "host" and execution_env_priority "invalid-value" Then the bug 1079 command should fail And the bug 1079 output should contain "Invalid execution env priority" -# @tdd_issue @tdd_issue_1079 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_1079 @tdd_expected_fail @tdd_issue_4178 Scenario: Bug #1079 - project context show reflects persisted execution-env-priority When I run bug 1079 context set on "local/bug1079-app" with execution_environment "host" and execution_env_priority "override" Then the bug 1079 command should succeed diff --git a/features/project_create_persist.feature b/features/project_create_persist.feature index 69030cf05..e17b31511 100644 --- a/features/project_create_persist.feature +++ b/features/project_create_persist.feature @@ -7,15 +7,13 @@ Feature: Project create persists to database Background: Given a fresh project-persist database is initialised -# @tdd_issue @tdd_issue_589 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_589 @tdd_issue_4178 Scenario: Created project appears in project list When I create a project named "local/my-app" via the persist CLI And I list projects via the persist CLI Then the persist project list should contain "local/my-app" -# @tdd_issue @tdd_issue_589 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_589 @tdd_issue_4178 Scenario: Multiple created projects all appear in list When I create a project named "local/alpha" via the persist CLI And I create a project named "local/beta" via the persist CLI @@ -23,15 +21,13 @@ Feature: Project create persists to database Then the persist project list should contain "local/alpha" And the persist project list should contain "local/beta" -# @tdd_issue @tdd_issue_589 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_589 @tdd_issue_4178 Scenario: Bare project name uses default namespace and persists When I create a project named "my-app" via the persist CLI And I list projects via the persist CLI Then the persist project list should contain "local/my-app" -# @tdd_issue @tdd_issue_589 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_589 @tdd_issue_4178 Scenario: Creating a duplicate project produces an error When I create a project named "local/dup-proj" via the persist CLI And I attempt to create a duplicate project named "local/dup-proj" via the persist CLI diff --git a/features/project_show_after_create.feature b/features/project_show_after_create.feature index 5df35634d..b2893bd22 100644 --- a/features/project_show_after_create.feature +++ b/features/project_show_after_create.feature @@ -7,16 +7,14 @@ Feature: Project show displays a created project Background: Given a fresh project-show database is initialised -# @tdd_issue @tdd_issue_590 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_590 @tdd_issue_4178 Scenario: Show displays a project that was just created When I create a project named "local/my-app" via the project-show CLI And I show the project "local/my-app" via the project-show CLI Then the project-show output should contain "local/my-app" And the project-show exit code should be 0 -# @tdd_issue @tdd_issue_590 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_590 @tdd_issue_4178 Scenario: Show displays correct details for a created project with description When I create a described project named "local/webapp" with description "My web app" via the project-show CLI And I show the project "local/webapp" via the project-show CLI @@ -24,8 +22,7 @@ Feature: Project show displays a created project And the project-show output should contain "My web app" And the project-show exit code should be 0 -# @tdd_issue @tdd_issue_590 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_590 @tdd_issue_4178 Scenario: Show returns error for a project that does not exist When I show the project "local/nonexistent" via the project-show CLI Then the project-show output should contain "not found" diff --git a/features/repo_indexing_cli.feature b/features/repo_indexing_cli.feature index 7166fee35..b06c11a0c 100644 --- a/features/repo_indexing_cli.feature +++ b/features/repo_indexing_cli.feature @@ -28,8 +28,7 @@ Feature: Repository indexing CLI commands Then the repo command should succeed And the repo output should contain "Incremental refresh complete" -# @tdd_issue @tdd_issue_4259 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4259 @tdd_expected_fail Scenario: Index with JSON output format Given a registered git-checkout resource "local/json-repo" with a temp directory When I run repo index-json on resource "local/json-repo" @@ -61,8 +60,7 @@ Feature: Repository indexing CLI commands Then the repo command should succeed And the repo output should contain "No index found" -# @tdd_issue @tdd_issue_4259 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4259 @tdd_expected_fail Scenario: Status with JSON output format Given a registered git-checkout resource "local/json-status-repo" with a temp directory And I have already indexed "local/json-status-repo" @@ -78,8 +76,7 @@ Feature: Repository indexing CLI commands Then the repo command should fail And the repo output should contain "Resource not found" -# @tdd_issue @tdd_issue_4259 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4259 @tdd_expected_fail Scenario: Status with no index in JSON format Given a registered git-checkout resource "local/noindex-json" with a temp directory When I run repo status-json on resource "local/noindex-json" diff --git a/features/repositories_error_handling_coverage.feature b/features/repositories_error_handling_coverage.feature index 686614ac9..a49f02f36 100644 --- a/features/repositories_error_handling_coverage.feature +++ b/features/repositories_error_handling_coverage.feature @@ -399,8 +399,7 @@ Feature: Repository error handling coverage for major repository classes # --- create: IntegrityError (non-UNIQUE) -> DatabaseError ----------------- @plan_repo @transient_error -# @tdd_issue @tdd_issue_4260 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4260 @tdd_expected_fail Scenario: LifecyclePlanRepository create raises DatabaseError on non-UNIQUE IntegrityError Given a lifecycle plan repository with session raising non-UNIQUE IntegrityError on flush When a lifecycle plan is created and a repo error is expected @@ -409,8 +408,7 @@ Feature: Repository error handling coverage for major repository classes # --- create: OperationalError -> DatabaseError ---------------------------- @plan_repo @transient_error -# @tdd_issue @tdd_issue_4260 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4260 @tdd_expected_fail Scenario: LifecyclePlanRepository create raises DatabaseError on OperationalError Given a lifecycle plan repository with session raising OperationalError on flush When a lifecycle plan is created and a repo error is expected diff --git a/features/resource_cli.feature b/features/resource_cli.feature index 02b3f24ba..e1033fafa 100644 --- a/features/resource_cli.feature +++ b/features/resource_cli.feature @@ -13,8 +13,7 @@ Feature: Resource CLI commands Then the resource output should contain "git-checkout" And the resource output should contain "fs-directory" -# @tdd_issue @tdd_issue_4261 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4261 @tdd_expected_fail Scenario: List resource types in JSON format Given built-in types are bootstrapped When I run resource type list with format "json" diff --git a/features/resource_cli_coverage.feature b/features/resource_cli_coverage.feature index f8c90612b..69a4fd379 100644 --- a/features/resource_cli_coverage.feature +++ b/features/resource_cli_coverage.feature @@ -218,8 +218,7 @@ Feature: Resource CLI error path coverage # ---- --clone-into flag coverage ---- -# @tdd_issue @tdd_issue_4262 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4262 @tdd_expected_fail Scenario: resource add container-instance with --clone-into stores clone_into property Given built-in types are bootstrapped When I run resource add "container-instance" "local/clone-test" with clone-into "https://github.com/acme/api.git:/workspace" diff --git a/features/resource_list_lifecycle_state.feature b/features/resource_list_lifecycle_state.feature index 3463b2d0b..0c411b472 100644 --- a/features/resource_list_lifecycle_state.feature +++ b/features/resource_list_lifecycle_state.feature @@ -52,8 +52,7 @@ Feature: agents resource list shows devcontainer lifecycle state column When I run resource list with all flag Then the resource output should not contain "Devcontainer detected" -# @tdd_issue @tdd_issue_4263 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4263 @tdd_expected_fail Scenario: resource list JSON output includes lifecycle_state for devcontainer-instance Given a devcontainer-instance resource is registered When I run resource list with all flag and format "json" diff --git a/features/resource_type_bootstrap_fs.feature b/features/resource_type_bootstrap_fs.feature index ed2cd506e..d59e9e597 100644 --- a/features/resource_type_bootstrap_fs.feature +++ b/features/resource_type_bootstrap_fs.feature @@ -17,8 +17,7 @@ Feature: Built-in fs-directory Resource Type Bootstrap # ResourceRegistryService.__init__(), you will need to update the Given # step to exercise the init path instead of constructing a bare service. -# @tdd_issue @tdd_issue_523 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_523 @tdd_issue_4178 Scenario: fs-directory type exists after init without explicit bootstrap call Given a fresh in-memory resource registry without bootstrap When I query the fs bootstrap resource type registry for "fs-directory" @@ -26,8 +25,7 @@ Feature: Built-in fs-directory Resource Type Bootstrap # ── Regression: bootstrap function itself works correctly ── -# @tdd_issue @tdd_issue_523 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_523 @tdd_issue_4178 Scenario: After initialization fs-directory type exists in the registry Given a fresh in-memory resource registry with bootstrap When I query the fs bootstrap resource type registry for "fs-directory" @@ -37,8 +35,7 @@ Feature: Built-in fs-directory Resource Type Bootstrap # ── CLI add command ──────────────────────────────────────── -# @tdd_issue @tdd_issue_523 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_523 @tdd_issue_4178 Scenario: resource add fs-directory succeeds after bootstrap Given a fresh in-memory resource registry with bootstrap When I run resource add for type "fs-directory" named "local/test" with path "/tmp/test" diff --git a/features/resource_type_bootstrap_fs_mount.feature b/features/resource_type_bootstrap_fs_mount.feature index 9b6040962..b2d4d2ae7 100644 --- a/features/resource_type_bootstrap_fs_mount.feature +++ b/features/resource_type_bootstrap_fs_mount.feature @@ -5,8 +5,7 @@ Feature: Built-in fs-mount Resource Type Bootstrap # ── Bug reproduction: fs-mount must be in BUILTIN_TYPES ─────────── -# @tdd_issue @tdd_issue_2911 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_2911 @tdd_issue_4178 Scenario: fs-mount type exists after bootstrap Given a fresh in-memory resource registry with bootstrap When I query the fs bootstrap resource type registry for "fs-mount" @@ -14,32 +13,28 @@ Feature: Built-in fs-mount Resource Type Bootstrap And the bootstrap fs resource type kind should be "physical" And the bootstrap fs resource type sandbox_strategy should be "copy_on_write" -# @tdd_issue @tdd_issue_2911 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_2911 @tdd_issue_4178 Scenario: fs-mount is user-addable after bootstrap Given a fresh in-memory resource registry with bootstrap When I query the fs bootstrap resource type registry for "fs-mount" Then the bootstrap fs resource type "fs-mount" should exist And the bootstrap fs resource type user_addable should be true -# @tdd_issue @tdd_issue_2911 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_2911 @tdd_issue_4178 Scenario: fs-mount has fs-directory as child type after bootstrap Given a fresh in-memory resource registry with bootstrap When I query the fs bootstrap resource type registry for "fs-mount" Then the bootstrap fs resource type "fs-mount" should exist And the bootstrap fs resource type child_types should contain "fs-directory" -# @tdd_issue @tdd_issue_2911 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_2911 @tdd_issue_4178 Scenario: fs-mount has no parent types after bootstrap Given a fresh in-memory resource registry with bootstrap When I query the fs bootstrap resource type registry for "fs-mount" Then the bootstrap fs resource type "fs-mount" should exist And the bootstrap fs resource type parent_types should be empty -# @tdd_issue @tdd_issue_2911 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_2911 @tdd_issue_4178 Scenario: resource add fs-mount succeeds after bootstrap Given a fresh in-memory resource registry with bootstrap When I run resource add for type "fs-mount" named "local/test-mount" with path "/tmp" @@ -47,8 +42,7 @@ Feature: Built-in fs-mount Resource Type Bootstrap And the resource add output should contain "Added resource" And the resource add output should not contain "Resource type not found" -# @tdd_issue @tdd_issue_2911 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_2911 @tdd_issue_4178 Scenario: fs-directory can reference fs-mount as parent type after bootstrap Given a fresh in-memory resource registry with bootstrap When I query the fs bootstrap resource type registry for "fs-directory" diff --git a/features/resource_type_bootstrap_git.feature b/features/resource_type_bootstrap_git.feature index 4a487ab84..30a908598 100644 --- a/features/resource_type_bootstrap_git.feature +++ b/features/resource_type_bootstrap_git.feature @@ -25,8 +25,7 @@ Feature: Built-in git-checkout type bootstrap on initialization # ── Regression: bootstrap function itself works correctly ── -# @tdd_issue @tdd_issue_524 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_524 @tdd_issue_4178 Scenario: After initialization the git-checkout type exists in the resource type registry Given a bootstrap-git fresh in-memory resource registry with bootstrap When I query the bootstrap-git resource type registry for "git-checkout" @@ -38,8 +37,7 @@ Feature: Built-in git-checkout type bootstrap on initialization # ── CLI resource add succeeds ────────────────────────────── -# @tdd_issue @tdd_issue_524 @tdd_expected_fail @tdd_issue_4178 @skip - @skip + @tdd_issue @tdd_issue_524 @tdd_issue_4178 Scenario: agents resource add git-checkout succeeds without Resource type not found error Given a bootstrap-git fresh in-memory resource registry with bootstrap When I run bootstrap-git resource add for type "git-checkout" named "local/test" with path "/tmp/repo" and branch "main" diff --git a/features/security_template_coverage_boost.feature b/features/security_template_coverage_boost.feature index 8ba950848..90f6a0cce 100644 --- a/features/security_template_coverage_boost.feature +++ b/features/security_template_coverage_boost.feature @@ -9,8 +9,7 @@ Feature: Coverage boost for security template branch # and includes (lines 200-213) # ========================================================================= -# @tdd_issue @tdd_issue_4267 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4267 @tdd_expected_fail Scenario: Validate skill with tool registry reports missing tool refs Given a skill registry with a mock tool registry And a skill definition with tool ref "nonexistent-tool" diff --git a/features/session_cli_coverage_boost.feature b/features/session_cli_coverage_boost.feature index 677676d9f..724547fd6 100644 --- a/features/session_cli_coverage_boost.feature +++ b/features/session_cli_coverage_boost.feature @@ -134,8 +134,7 @@ Feature: Session CLI Coverage Boost When session coverage boost I invoke the export command to stdout Then session coverage boost the exit code is 0 -# @tdd_issue @tdd_issue_4268 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4268 @tdd_expected_fail Scenario: export command to file Given session coverage boost a mock service for export And session coverage boost a temporary directory for export diff --git a/features/session_list_error.feature b/features/session_list_error.feature index ff7451260..ea38934ad 100644 --- a/features/session_list_error.feature +++ b/features/session_list_error.feature @@ -53,8 +53,7 @@ Feature: Session list command handles missing database gracefully And the session-list-error output should contain "total:" @tdd_issue @tdd_issue_554 -# @tdd_issue @tdd_issue_4270 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4270 @tdd_expected_fail Scenario: Session list works with YAML output format Given a session-list-error service with a pre-populated session When I invoke session-list-error list with format "yaml" @@ -73,8 +72,7 @@ Feature: Session list command handles missing database gracefully And the session-list-error output should not contain "AttributeError" @tdd_issue @tdd_issue_554 -# @tdd_issue @tdd_issue_4270 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4270 @tdd_expected_fail Scenario: Empty session list with YAML format produces valid YAML When I invoke session-list-error list with format "yaml" Then the session-list-error command should exit successfully diff --git a/features/session_list_summary_dedup.feature b/features/session_list_summary_dedup.feature index ec8d06336..934b2557f 100644 --- a/features/session_list_summary_dedup.feature +++ b/features/session_list_summary_dedup.feature @@ -1,5 +1,4 @@ -# @tdd_issue @tdd_issue_3046 @tdd_expected_fail @tdd_issue_4178 @skip -@skip +@tdd_issue @tdd_issue_3046 @tdd_expected_fail @tdd_issue_4178 Feature: Session list summary consistency between JSON and rich table output As a developer I want the session list summary values to be consistent between JSON and rich table output @@ -28,16 +27,6 @@ Feature: Session list summary consistency between JSON and rich table output And I invoke session list with rich format Then the JSON summary oldest should appear in the rich table summary panel -# @tdd_issue @tdd_issue_4271 @tdd_expected_fail @skip - @skip - Scenario: Rich table summary panel contains all required fields - When I invoke session list with rich format - Then the rich table output contains "Total:" - And the rich table output contains "Most Recent:" - And the rich table output contains "Oldest:" - And the rich table output contains "Total Messages:" - And the rich table output contains "Storage:" - Scenario: JSON output summary contains all required fields When I invoke session list with JSON format Then the JSON output has a summary key with total diff --git a/features/skill_cli.feature b/features/skill_cli.feature index 527ec25b7..32c3de7e8 100644 --- a/features/skill_cli.feature +++ b/features/skill_cli.feature @@ -321,8 +321,7 @@ Feature: Skill CLI commands And the skill CLI output should contain "Read-Only" And the skill CLI output should contain "✓ OK" -# @tdd_issue @tdd_issue_4272 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4272 @tdd_expected_fail Scenario: Refresh single skill with --format json Given the skill "local/file-reader" is registered with tools When I run skill CLI refresh "local/file-reader" with --format json @@ -377,8 +376,7 @@ Feature: Skill CLI commands # Enhanced outputs — capability summary in JSON/YAML # ─────────────────────────────────────────────────────── -# @tdd_issue @tdd_issue_4272 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4272 @tdd_expected_fail Scenario: List with --format json includes capability summary Given the skill "local/file-reader" is registered with tools When I run skill CLI list with --format json @@ -386,8 +384,7 @@ Feature: Skill CLI commands And the skill CLI output should be valid JSON And the skill CLI JSON output should have field "capability_summary" in first skill -# @tdd_issue @tdd_issue_4272 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4272 @tdd_expected_fail Scenario: Show with --format json includes capability summary Given the skill "local/file-reader" is registered with tools When I run skill CLI show "local/file-reader" with --format json @@ -396,8 +393,7 @@ Feature: Skill CLI commands And the skill CLI JSON output should have field "capability_summary" And the skill CLI JSON output should have field "tool_count" -# @tdd_issue @tdd_issue_4272 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4272 @tdd_expected_fail Scenario: Tools with --format json includes capability summary Given the skill "local/file-reader" is registered with tools When I run skill CLI tools "local/file-reader" with --format json diff --git a/features/tdd_a2a_sdk_dependency.feature b/features/tdd_a2a_sdk_dependency.feature index bc97e950d..92f23ff48 100644 --- a/features/tdd_a2a_sdk_dependency.feature +++ b/features/tdd_a2a_sdk_dependency.feature @@ -1,5 +1,4 @@ -# @tdd_issue @tdd_issue_2922 @tdd_expected_fail @tdd_issue_4178 @skip -@skip +@tdd_issue @tdd_issue_2922 @tdd_issue_4178 Feature: A2A Python SDK is a declared project dependency As a CleverAgents developer I want the A2A Python SDK to be listed in pyproject.toml dependencies @@ -8,20 +7,17 @@ Feature: A2A Python SDK is a declared project dependency Background: Given the pyproject.toml file exists at "pyproject.toml" -# @tdd_issue @tdd_issue_4273 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4273 Scenario: a2a-sdk is listed in project dependencies When I read the project dependencies from pyproject.toml Then the dependency list should include a package that provides the "a2a" module -# @tdd_issue @tdd_issue_4366 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4366 Scenario: a2a module is importable as a project dependency When I attempt to import the "a2a" module Then the import should succeed without errors -# @tdd_issue @tdd_issue_4273 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4273 Scenario: a2a SDK provides the A2AClient class When I import "a2a.client" and access "A2AClient" Then the "A2AClient" class should be available diff --git a/features/tdd_automation_profile_session_leak.feature b/features/tdd_automation_profile_session_leak.feature index 343b3917f..4689bfdad 100644 --- a/features/tdd_automation_profile_session_leak.feature +++ b/features/tdd_automation_profile_session_leak.feature @@ -1,5 +1,4 @@ -# @tdd_issue @tdd_issue_987 @tdd_expected_fail @tdd_issue_4178 @skip -@skip +@tdd_issue @tdd_issue_987 @tdd_issue_4178 Feature: TDD Bug #987 — AutomationProfileRepository session leak As a developer I want to verify that AutomationProfileRepository closes sessions @@ -17,58 +16,50 @@ Feature: TDD Bug #987 — AutomationProfileRepository session leak auto_commit mode for both success and error paths across all public methods. -# @tdd_issue @tdd_issue_4274 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4274 Scenario: upsert closes session in auto_commit mode on success Given an AutomationProfileRepository with auto_commit enabled and a tracking session factory When I upsert a valid automation profile via the repository Then the tracking session should have been closed -# @tdd_issue @tdd_issue_4274 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4274 Scenario: delete closes session in auto_commit mode on success Given an AutomationProfileRepository with auto_commit enabled and a tracking session factory And a persisted automation profile named "local/leak-test-profile" When I delete the automation profile "local/leak-test-profile" via the repository Then the tracking session should have been closed -# @tdd_issue @tdd_issue_4274 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4274 Scenario: upsert closes session in auto_commit mode on database error Given an AutomationProfileRepository with auto_commit enabled and a failing session factory When I attempt to upsert a profile that triggers a database error Then the tracking session should have been closed despite the error -# @tdd_issue @tdd_issue_4274 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4274 Scenario: delete closes session in auto_commit mode on database error Given an AutomationProfileRepository with auto_commit enabled, a pre-populated profile, and a failing-flush tracking session When I attempt to delete a profile that triggers a database error Then the tracking session should have been closed despite the delete error -# @tdd_issue @tdd_issue_4274 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4274 Scenario: get_by_name closes session in auto_commit mode on success Given an AutomationProfileRepository with auto_commit enabled and a tracking session factory When I look up a profile by name via the repository Then the tracking session should have been closed -# @tdd_issue @tdd_issue_4274 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4274 Scenario: list_all closes session in auto_commit mode on success Given an AutomationProfileRepository with auto_commit enabled and a tracking session factory When I list all profiles via the repository Then the tracking session should have been closed -# @tdd_issue @tdd_issue_4274 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4274 Scenario: get_by_name closes session in auto_commit mode on database error Given an AutomationProfileRepository with auto_commit enabled and a failing-query session factory When I attempt to look up a profile that triggers a database error Then the tracking session should have been closed despite the get_by_name error -# @tdd_issue @tdd_issue_4274 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4274 Scenario: list_all closes session in auto_commit mode on database error Given an AutomationProfileRepository with auto_commit enabled and a failing-query session factory When I attempt to list profiles that triggers a database error diff --git a/features/tdd_budget_eviction_deletes_not_demotes.feature b/features/tdd_budget_eviction_deletes_not_demotes.feature index f8e2a9b2d..0b68171f7 100644 --- a/features/tdd_budget_eviction_deletes_not_demotes.feature +++ b/features/tdd_budget_eviction_deletes_not_demotes.feature @@ -14,16 +14,14 @@ Feature: TDD Issue #1152 — budget eviction permanently deletes hot-tier fragme # The @tag inverts the result so CI passes while the # bug is still present. When bug #1152 is fixed, the @# tag must be removed so the test runs normally. -# @tdd_issue @tdd_issue_4275 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4275 @tdd_expected_fail Scenario: Budget-evicted hot-tier fragment is demoted to warm tier instead of deleted Given a context tier service with a hot tier budget of 100 tokens for eviction test And the hot tier contains two 50-token fragments filling the budget for eviction test When I store a third 50-token fragment in the hot tier triggering budget eviction Then the evicted fragment should exist in the warm tier not be permanently deleted -# @tdd_issue @tdd_issue_4275 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4275 @tdd_expected_fail Scenario: Budget eviction via evict_lru also demotes to warm tier instead of deleting Given a context tier service with a hot tier budget of 100 tokens for eviction test And the hot tier contains two 50-token fragments filling the budget for eviction test diff --git a/features/tdd_checkpoint_real_rollback.feature b/features/tdd_checkpoint_real_rollback.feature index d5a7b68c7..5942e4f84 100644 --- a/features/tdd_checkpoint_real_rollback.feature +++ b/features/tdd_checkpoint_real_rollback.feature @@ -1,5 +1,4 @@ -# @tdd_issue @tdd_issue_822 @tdd_expected_fail @tdd_issue_4178 @skip -@skip +@tdd_issue @tdd_issue_822 @tdd_issue_4178 Feature: TDD Issue #822 — checkpoint rollback is simulated, does not execute real git reset As a developer I want to verify that CheckpointService.rollback_to_checkpoint() @@ -12,8 +11,7 @@ Feature: TDD Issue #822 — checkpoint rollback is simulated, does not execute r to their checkpoint-time content. Currently they are not, proving the bug exists. -# @tdd_issue @tdd_issue_4276 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4276 Scenario: Rollback restores file content to checkpoint state Given a temporary git workspace with an initial committed file And a checkpoint is created from the current commit @@ -21,8 +19,7 @@ Feature: TDD Issue #822 — checkpoint rollback is simulated, does not execute r When I invoke rollback_to_checkpoint targeting the checkpoint Then the tracked file content should match the checkpoint state -# @tdd_issue @tdd_issue_4276 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4276 Scenario: Rollback removes files added after the checkpoint Given a temporary git workspace with an initial committed file And a checkpoint is created from the current commit diff --git a/features/tdd_cli_incomplete_subcommand_registration.feature b/features/tdd_cli_incomplete_subcommand_registration.feature index 082abf736..e9855d14a 100644 --- a/features/tdd_cli_incomplete_subcommand_registration.feature +++ b/features/tdd_cli_incomplete_subcommand_registration.feature @@ -15,22 +15,19 @@ Feature: TDD Issue #2604 — Incomplete subcommand registration on error CLI exits with a non-zero exit code instead of entering a partially initialized state. -# @tdd_issue @tdd_issue_4277 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4277 @tdd_expected_fail Scenario: Bug #2604 — subcommand registration failure exits with non-zero code Given the CLI subcommand import raises an ImportError during registration When the CLI is invoked with any command Then the CLI exits with a non-zero exit code -# @tdd_issue @tdd_issue_4277 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4277 @tdd_expected_fail Scenario: Bug #2604 — subcommand registration failure prints error message Given the CLI subcommand import raises an ImportError during registration When the CLI is invoked with any command Then the error output contains "Failed to register subcommands" -# @tdd_expected_fail - @skip + @tdd_expected_fail Scenario: Bug #2604 — old behaviour silently returns on registration error Given the CLI subcommand import raises an ImportError during registration When the CLI is invoked with any command diff --git a/features/tdd_context_tier_runtime.feature b/features/tdd_context_tier_runtime.feature index 30392ef8f..1399dea0c 100644 --- a/features/tdd_context_tier_runtime.feature +++ b/features/tdd_context_tier_runtime.feature @@ -1,5 +1,4 @@ -# @tdd_issue @tdd_issue_821 @mock_only @tdd_expected_fail @tdd_issue_4178 @skip -@skip +@tdd_issue @tdd_issue_821 @mock_only @tdd_issue_4178 Feature: TDD Issue #821 — context tier service has data models but no runtime logic As a developer I want to verify that ContextTierService automatically promotes, demotes, @@ -17,24 +16,21 @@ Feature: TDD Issue #821 — context tier service has data models but no runtime These tests serve as a permanent regression guard for the fix. -# @tdd_issue @tdd_issue_4278 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4278 Scenario: Promotion on repeated access moves fragment to a higher tier Given a context tier service with default budget And a fragment stored in the cold tier When I access the fragment 5 times via get Then the fragment should have been promoted to warm or hot tier -# @tdd_issue @tdd_issue_4278 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4278 Scenario: Demotion on staleness moves fragment to a lower tier Given a context tier service with default budget And a fragment stored in the hot tier with a stale last_accessed timestamp When I invoke the staleness enforcement runtime Then the fragment should have been demoted to warm or cold tier -# @tdd_issue @tdd_issue_4278 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4278 Scenario: Eviction on hot tier budget overflow removes oldest fragment Given a context tier service with a small hot tier budget of 100 tokens And the hot tier is filled to its token budget limit diff --git a/features/tdd_correction_checkpoint_wiring.feature b/features/tdd_correction_checkpoint_wiring.feature index c627c00fa..62b1595f6 100644 --- a/features/tdd_correction_checkpoint_wiring.feature +++ b/features/tdd_correction_checkpoint_wiring.feature @@ -1,5 +1,4 @@ -# @tdd_issue @tdd_issue_986 @mock_only @tdd_expected_fail @tdd_issue_4178 @skip -@skip +@tdd_issue @tdd_issue_986 @mock_only @tdd_issue_4178 Feature: TDD Issue #986 — CorrectionService missing checkpoint_service wiring in DI container As a developer I want to verify that CorrectionService receives checkpoint_service @@ -11,15 +10,13 @@ Feature: TDD Issue #986 — CorrectionService missing checkpoint_service wiring The CLI correct command also uses the container-provided service instead of creating an ad-hoc instance. -# @tdd_issue @tdd_issue_4279 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4279 Scenario: DI container wires checkpoint_service into CorrectionService Given tccw a fresh DI container with an in-memory database When tccw I resolve the correction_service from the container Then tccw the correction_service should have a non-None checkpoint_service -# @tdd_issue @tdd_issue_4279 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4279 Scenario: Container-provided CorrectionService checkpoint_service is a CheckpointService instance Given tccw a fresh DI container with an in-memory database When tccw I resolve the correction_service from the container diff --git a/features/tdd_e2e_implicit_init.feature b/features/tdd_e2e_implicit_init.feature index 7d79cca5b..843153f81 100644 --- a/features/tdd_e2e_implicit_init.feature +++ b/features/tdd_e2e_implicit_init.feature @@ -20,8 +20,7 @@ Feature: TDD Bug #1023 — CLI commands should succeed without explicit init fail until the bug is fixed. The @tag inverts the result so CI remains green while the defect is open. -# @tdd_issue @tdd_issue_4280 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4280 @tdd_expected_fail Scenario: Resource add succeeds in a fresh environment without explicit init Given a fresh isolated environment for tdd-implicit-init And CLEVERAGENTS_AUTO_APPLY_MIGRATIONS is set to true @@ -29,8 +28,7 @@ Feature: TDD Bug #1023 — CLI commands should succeed without explicit init Then the tdd-implicit-init command should exit with code 0 And the tdd-implicit-init command output should contain "tdd-test-resource" -# @tdd_issue @tdd_issue_4280 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4280 @tdd_expected_fail Scenario: Project create succeeds in a fresh environment without explicit init Given a fresh isolated environment for tdd-implicit-init And CLEVERAGENTS_AUTO_APPLY_MIGRATIONS is set to true diff --git a/features/tdd_event_bus_exception_swallow.feature b/features/tdd_event_bus_exception_swallow.feature index 6dcbed274..72c8a3d80 100644 --- a/features/tdd_event_bus_exception_swallow.feature +++ b/features/tdd_event_bus_exception_swallow.feature @@ -19,15 +19,13 @@ Feature: TDD Issue #988 — ReactiveEventBus.emit() swallows exception details See CONTRIBUTING.md > Bug Fix Workflow > TDD Issue Test Tags. -# @tdd_issue @tdd_issue_4367 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4367 Scenario: Bug #988 — emit() logs exception message when handler raises Given a ReactiveEventBus with a handler that raises a ValueError When I emit an event that triggers the failing handler Then the warning log should contain the exception message text -# @tdd_expected_fail - @skip + @tdd_expected_fail Scenario: Bug #988 — emit() logs traceback via exc_info when handler raises Given a ReactiveEventBus with a handler that raises a ValueError When I emit an event that triggers the failing handler diff --git a/features/tdd_exec_env_resolution_precedence.feature b/features/tdd_exec_env_resolution_precedence.feature index ef6c7c381..94ecaf03e 100644 --- a/features/tdd_exec_env_resolution_precedence.feature +++ b/features/tdd_exec_env_resolution_precedence.feature @@ -1,5 +1,4 @@ -# @tdd_issue @tdd_issue_1080 @tdd_expected_fail @tdd_issue_4178 @mock_only @skip -@skip +@tdd_issue @tdd_issue_1080 @tdd_expected_fail @tdd_issue_4178 @mock_only Feature: TDD Bug #1080 — execution environment resolution ignores project-level override As a developer I want execution environment resolution to honour the 6-level precedence chain @@ -31,23 +30,8 @@ Feature: TDD Bug #1080 — execution environment resolution ignores project-leve # The @mock_only tag restricts this feature to in-process mock execution; # it does not require any external services or container infrastructure. -# @tdd_expected_fail - @skip + @tdd_expected_fail Scenario: Bug #1080 - Project-level override beats plan-level fallback (precedence level 2 vs 4) Given a precedence-aware execution environment resolver When I resolve precedence with plan env "host" at priority "fallback" and project env "container" at priority "override" Then the precedence-resolved environment should be "container" - -# @tdd_issue @tdd_issue_4281 @tdd_expected_fail @skip - @skip - Scenario: Regression guard - Plan-level override still beats project-level override (precedence level 1 vs 2) - Given a precedence-aware execution environment resolver - When I resolve precedence with plan env "host" at priority "override" and project env "container" at priority "override" - Then the precedence-resolved environment should be "host" - -# @tdd_issue @tdd_issue_4281 @tdd_expected_fail @skip - @skip - Scenario: Regression guard - Project-level override beats host default (precedence level 2 vs 6) - Given a precedence-aware execution environment resolver - When I resolve precedence with no plan env and project env "container" at priority "override" - Then the precedence-resolved environment should be "container" diff --git a/features/tdd_indentation_library_try_except.feature b/features/tdd_indentation_library_try_except.feature index 7dc2b42c9..f4ee5b4dd 100644 --- a/features/tdd_indentation_library_try_except.feature +++ b/features/tdd_indentation_library_try_except.feature @@ -1,5 +1,4 @@ -# @tdd_issue @tdd_issue_2845 @tdd_expected_fail @tdd_issue_4178 @skip -@skip +@tdd_issue @tdd_issue_2845 @tdd_issue_4178 Feature: TDD Issue #2845 — fix_python_indentation handles try...except...finally correctly As a Robot Framework user I want fix_python_indentation to correctly reconstruct indentation for try...except...finally blocks @@ -8,8 +7,7 @@ Feature: TDD Issue #2845 — fix_python_indentation handles try...except...final Background: Given the fix_python_indentation function is available -# @tdd_issue @tdd_issue_4282 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4282 Scenario: Single except clause produces valid Python When I fix indentation for a try block with a single except clause Then the indentation result should be syntactically valid Python @@ -17,39 +15,34 @@ Feature: TDD Issue #2845 — fix_python_indentation handles try...except...final And the except clause should be at the same level as try And the except body should be indented one level -# @tdd_issue @tdd_issue_4282 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4282 Scenario: Multiple except clauses produce valid Python When I fix indentation for a try block with multiple except clauses Then the indentation result should be syntactically valid Python And all except clauses should be at the same level as try And each except body should be indented one level -# @tdd_issue @tdd_issue_4282 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4282 Scenario: try...except...finally produces valid Python When I fix indentation for a try block with except and finally Then the indentation result should be syntactically valid Python And the finally clause should be at the same level as try And the finally body should be indented one level -# @tdd_issue @tdd_issue_4282 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4282 Scenario: Nested try blocks produce valid Python When I fix indentation for nested try blocks Then the indentation result should be syntactically valid Python And the inner try should be indented one level inside the outer try And the outer except should be at the same level as the outer try -# @tdd_issue @tdd_issue_4282 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4282 Scenario: Nested try with finally then outer except produces valid Python When I fix indentation for nested try with inner finally and outer except Then the indentation result should be syntactically valid Python And the outer except should be at the same level as the outer try -# @tdd_issue @tdd_issue_4282 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4282 Scenario: Code after try block produces valid Python When I fix indentation for code that follows a try block Then the indentation result should be syntactically valid Python diff --git a/features/tdd_invariant_persistence.feature b/features/tdd_invariant_persistence.feature index e62d45a83..22e8fa44f 100644 --- a/features/tdd_invariant_persistence.feature +++ b/features/tdd_invariant_persistence.feature @@ -23,31 +23,27 @@ Feature: TDD Issue #1022 — InvariantService invariants lost across process res the process exits. These tests simulate separate process invocations by creating fresh service instances and verifying cross-instance data visibility. -# @tdd_issue @tdd_issue_4283 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4283 @tdd_expected_fail Scenario: Invariant added in one service instance is visible in a fresh instance Given I add a project invariant "All APIs must validate auth tokens" to project "local/api-service" via invariant service instance A When I create a fresh invariant service instance B And I list project invariants for "local/api-service" via instance B Then the invariant list from instance B should contain "All APIs must validate auth tokens" -# @tdd_issue @tdd_issue_4283 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4283 @tdd_expected_fail Scenario: Global invariant persists across simulated process restarts Given I add a global invariant "Never delete production data" via invariant service instance A When I create a fresh invariant service instance B And I list global invariants via instance B Then the invariant list from instance B should contain "Never delete production data" -# @tdd_issue @tdd_issue_4283 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4283 @tdd_expected_fail Scenario: Invariant added via CLI add is visible via CLI list in a new invocation Given I invoke invariant add via CLI with "--project local/webapp" and text "All changes need tests" using service invocation 1 When I invoke invariant list via CLI with "--project local/webapp" using service invocation 2 Then the CLI list output from invocation 2 should contain "All changes need tests" -# @tdd_issue @tdd_issue_4283 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4283 @tdd_expected_fail Scenario: Invariant soft-deleted in a fresh instance after being added in another Given I add a project invariant "Temporary constraint" to project "local/temp" via invariant service instance A And I capture the invariant ID from instance A diff --git a/features/tdd_json_decode_crash_persistence.feature b/features/tdd_json_decode_crash_persistence.feature index 9864bd9d2..1a8f84b15 100644 --- a/features/tdd_json_decode_crash_persistence.feature +++ b/features/tdd_json_decode_crash_persistence.feature @@ -1,5 +1,4 @@ -# @tdd_issue @tdd_issue_989 @tdd_expected_fail @skip -@skip +@tdd_issue @tdd_issue_989 @tdd_expected_fail Feature: TDD Bug #989 — automation profile persistence crashes on corrupt JSON As a developer reading persisted automation profiles I want corrupt JSON payloads to be handled with a domain-specific error diff --git a/features/tdd_mcp_error_content_key.feature b/features/tdd_mcp_error_content_key.feature index f68efc40c..d5cb1b9df 100644 --- a/features/tdd_mcp_error_content_key.feature +++ b/features/tdd_mcp_error_content_key.feature @@ -1,12 +1,10 @@ -# @tdd_issue @tdd_issue_2158 @tdd_expected_fail @tdd_issue_4178 @skip -@skip +@tdd_issue @tdd_issue_2158 @tdd_issue_4178 Feature: TDD Issue #2158 — MCPToolAdapter.invoke() error extraction uses non-standard key MCPToolAdapter.invoke() currently reads error messages from result.get('error', 'unknown error'), but the MCP 1.4.0 protocol returns errors in content[0].text. This means every error from a real MCP 1.4.0 server is silently replaced with "unknown error". -# @tdd_issue @tdd_issue_4284 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4284 Scenario: invoke() extracts error message from MCP 1.4.0 content array Given a connected MCP adapter with a tool returning MCP 1.4.0 content-based error "read_file" When I invoke "read_file" with arguments {"path": "/path/to/file"} diff --git a/features/tdd_missing_validation_unit_tests_yaml.feature b/features/tdd_missing_validation_unit_tests_yaml.feature index 24fdd7eab..c86f702fa 100644 --- a/features/tdd_missing_validation_unit_tests_yaml.feature +++ b/features/tdd_missing_validation_unit_tests_yaml.feature @@ -1,5 +1,4 @@ -# @tdd_expected_fail @tdd_issue @tdd_issue_1039 -@skip +@tdd_expected_fail @tdd_issue @tdd_issue_1039 Feature: TDD Bug #1039 — Missing validations/unit-tests.yaml configuration As a developer I want to verify that the validation configuration file referenced by the diff --git a/features/tdd_plan_correct_auto_resolve.feature b/features/tdd_plan_correct_auto_resolve.feature index 40164e67c..c82e6ef20 100644 --- a/features/tdd_plan_correct_auto_resolve.feature +++ b/features/tdd_plan_correct_auto_resolve.feature @@ -30,8 +30,7 @@ Feature: TDD Bug #1025 — plan correct auto-resolve fails in isolated environme # This test captures bug #1025 and uses @until the # fix is merged. -# @tdd_issue @tdd_issue_4285 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4285 @tdd_expected_fail Scenario: plan correct auto-resolves active plan in revert mode Given tpcar a container with a plan in Execute/COMPLETE and an isolated auto-resolve path And tpcar a CorrectionService that succeeds for the target decision in revert mode @@ -39,8 +38,7 @@ Feature: TDD Bug #1025 — plan correct auto-resolve fails in isolated environme Then tpcar the command should exit successfully And tpcar the correction should have used the auto-resolved plan -# @tdd_issue @tdd_issue_4285 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4285 @tdd_expected_fail Scenario: plan correct auto-resolves active plan in append mode Given tpcar a container with a plan in Execute/COMPLETE and an isolated auto-resolve path And tpcar a CorrectionService that succeeds for the target decision in append mode diff --git a/features/tdd_regression_guards_exec_env.feature b/features/tdd_regression_guards_exec_env.feature new file mode 100644 index 000000000..d10ad86e5 --- /dev/null +++ b/features/tdd_regression_guards_exec_env.feature @@ -0,0 +1,18 @@ +@tdd_issue @tdd_issue_4281 +Feature: Regression guards — execution-env precedence (bug #4281) + # Scenarios previously blocked by the parent feature-level + # @tdd_expected_fail tag in tdd_exec_env_resolution_precedence.feature (bug #1080). + # The specific assertions below pass on the current codebase while + # bug #4281 remains open for other aspects of the issue. + + @tdd_issue @tdd_issue_4281 + Scenario: Regression guard - Plan-level override still beats project-level override (precedence level 1 vs 2) + Given a precedence-aware execution environment resolver + When I resolve precedence with plan env "host" at priority "override" and project env "container" at priority "override" + Then the precedence-resolved environment should be "host" + + @tdd_issue @tdd_issue_4281 + Scenario: Regression guard - Project-level override beats host default (precedence level 2 vs 6) + Given a precedence-aware execution environment resolver + When I resolve precedence with no plan env and project env "container" at priority "override" + Then the precedence-resolved environment should be "container" diff --git a/features/tdd_regression_guards_session_list.feature b/features/tdd_regression_guards_session_list.feature new file mode 100644 index 000000000..5abd1ae6f --- /dev/null +++ b/features/tdd_regression_guards_session_list.feature @@ -0,0 +1,18 @@ +@tdd_issue @tdd_issue_4271 +Feature: Regression guard — session list summary panel (bug #4271) + # Scenario previously blocked by the parent feature-level + # @tdd_expected_fail tag in session_list_summary_dedup.feature (bug #3046). + # The specific assertion below passes on the current codebase while + # bug #4271 remains open for other aspects of the issue. + + Background: + Given a session-list-summary mock service with two sessions + + @tdd_issue @tdd_issue_4271 + Scenario: Rich table summary panel contains all required fields + When I invoke session list with rich format + Then the rich table output contains "Total:" + And the rich table output contains "Most Recent:" + And the rich table output contains "Oldest:" + And the rich table output contains "Total Messages:" + And the rich table output contains "Storage:" diff --git a/features/tdd_server_connect_atomic_writes.feature b/features/tdd_server_connect_atomic_writes.feature index 8a42ccd10..b845a172a 100644 --- a/features/tdd_server_connect_atomic_writes.feature +++ b/features/tdd_server_connect_atomic_writes.feature @@ -1,5 +1,4 @@ -# @tdd_expected_fail @tdd_issue @tdd_issue_993 -@skip +@tdd_expected_fail @tdd_issue @tdd_issue_993 Feature: TDD Issue #993 — server_connect writes three config values non-atomically As a developer I want to verify that server_connect writes all three config values atomically diff --git a/features/tdd_session_create_di.feature b/features/tdd_session_create_di.feature index 3e5b703b2..7237216e8 100644 --- a/features/tdd_session_create_di.feature +++ b/features/tdd_session_create_di.feature @@ -19,8 +19,7 @@ Feature: TDD Issue #570 — session create DI container missing db provider When I invoke the session create command with actor "openai/gpt-4" Then the session create command should exit successfully -# @tdd_issue @tdd_issue_4368 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4368 Scenario: Session create command produces structured output via DI Given a CLI runner using the real session DI path When I invoke the session create command with format json diff --git a/features/tdd_session_create_persist.feature b/features/tdd_session_create_persist.feature index 3308f38e8..05eedd734 100644 --- a/features/tdd_session_create_persist.feature +++ b/features/tdd_session_create_persist.feature @@ -8,8 +8,7 @@ Feature: Bug #1141 — session create persists for session list Fixed: The A2A facade handler now skips creation when a session_id is already supplied in the params, preventing duplicate sessions (#1141). -# @tdd_issue @tdd_issue_4286 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4286 @tdd_expected_fail Scenario: Init then create should make list total increase from 0 to 1 Given a CLI runner using the real session DI path When I tdd1141 invoke init with force yes diff --git a/features/tdd_skill_add_regression.feature b/features/tdd_skill_add_regression.feature index eac5eefda..f4f247bd2 100644 --- a/features/tdd_skill_add_regression.feature +++ b/features/tdd_skill_add_regression.feature @@ -1,5 +1,4 @@ -# @tdd_issue @tdd_issue_980 @tdd_expected_fail @skip -@skip +@tdd_issue @tdd_issue_980 Feature: TDD Issue #980 — skill add cross-process persistence As a developer I want to verify that `agents skill add --config ` persists @@ -19,9 +18,6 @@ Feature: TDD Issue #980 — skill add cross-process persistence tag removed after fix in #980. @tdd_issue @tdd_issue_4287 - -# @tdd_issue @tdd_issue_4287 @tdd_expected_fail @skip - @skip Scenario: skill add in one process is visible to skill list in another Given a cross-process skill persistence environment When I add a skill via a CLI subprocess @@ -29,9 +25,6 @@ Feature: TDD Issue #980 — skill add cross-process persistence Then the cross-process skill list should contain the added skill @tdd_issue @tdd_issue_4287 - -# @tdd_issue @tdd_issue_4287 @tdd_expected_fail @skip - @skip Scenario: skill add persists config path across processes Given a cross-process skill persistence environment When I add a skill via a CLI subprocess diff --git a/features/tdd_sqlite_url_cwd.feature b/features/tdd_sqlite_url_cwd.feature index 13d1d5afb..cd48d848d 100644 --- a/features/tdd_sqlite_url_cwd.feature +++ b/features/tdd_sqlite_url_cwd.feature @@ -15,16 +15,14 @@ Feature: TDD Issue #1024 — SQLite DB URL resolves to CWD instead of CLEVERAGEN Bug: https://git.cleverthis.com/cleveragents/cleveragents-core/issues/1024 TDD: https://git.cleverthis.com/cleveragents/cleveragents-core/issues/1034 -# @tdd_issue @tdd_issue_4288 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4288 @tdd_expected_fail Scenario: Default database_url resolves inside CLEVERAGENTS_HOME not CWD Given a fresh CLEVERAGENTS_HOME temp directory for DB URL testing When I resolve the effective database URL from Settings Then the resolved database path should be inside CLEVERAGENTS_HOME And the resolved database path should not be inside the original CWD -# @tdd_issue @tdd_issue_4288 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4288 @tdd_expected_fail Scenario: Settings database_url default resolves inside CLEVERAGENTS_HOME Given a fresh CLEVERAGENTS_HOME temp directory for DB URL testing When I resolve the Settings database_url default diff --git a/features/tdd_subplan_spawn_orchestration.feature b/features/tdd_subplan_spawn_orchestration.feature index 90b7a9e6c..7cd50d0f9 100644 --- a/features/tdd_subplan_spawn_orchestration.feature +++ b/features/tdd_subplan_spawn_orchestration.feature @@ -12,8 +12,7 @@ Feature: TDD Issue #823 — subplan spawn creates metadata but does not orchestr tests assert the expected behaviour and will FAIL until the bug is fixed. The @tdd_expected_fail tag inverts the result so CI passes. -# @tdd_issue @tdd_issue_4289 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4289 Scenario: Spawn result contains child Plan domain objects Given a parent plan configured for subplan spawning And valid spawn entries for the parent plan @@ -21,8 +20,7 @@ Feature: TDD Issue #823 — subplan spawn creates metadata but does not orchestr Then the spawn result should contain child Plan domain objects And each child Plan should have parent_plan_id set to the parent -# @tdd_issue @tdd_issue_4289 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4289 Scenario: Child plans enter the strategize phase after spawn Given a parent plan configured for subplan spawning And valid spawn entries for the parent plan @@ -30,8 +28,7 @@ Feature: TDD Issue #823 — subplan spawn creates metadata but does not orchestr Then each child plan should be in the strategize phase And each child plan processing state should be queued -# @tdd_issue @tdd_issue_4289 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4289 Scenario: Parent plan tracks child plan lifecycle status Given a parent plan configured for subplan spawning And valid spawn entries for the parent plan diff --git a/features/tdd_tool_runner_env_precedence.feature b/features/tdd_tool_runner_env_precedence.feature index 920492846..b6feb5667 100644 --- a/features/tdd_tool_runner_env_precedence.feature +++ b/features/tdd_tool_runner_env_precedence.feature @@ -1,5 +1,4 @@ -# @tdd_issue @tdd_issue_2592 @tdd_bug @tdd_bug_2592 @mock_only @tdd_expected_fail @tdd_issue_4178 @skip -@skip +@tdd_issue @tdd_issue_2592 @tdd_bug @tdd_bug_2592 @mock_only @tdd_issue_4178 Feature: TDD Issue #2592 — ToolRunner.execute() 6-level execution environment precedence chain As the tool execution engine I want ToolRunner.execute() to apply the correct 6-level precedence chain @@ -7,57 +6,49 @@ Feature: TDD Issue #2592 — ToolRunner.execute() 6-level execution environment # ── Unit tests: 6-level precedence chain via ToolRunner.execute() ── -# @tdd_issue @tdd_issue_4290 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4290 Scenario: Plan override wins over devcontainer (Level 1 beats Level 3) Given a tool runner with a devcontainer-instance linked resource When I execute the tool with plan_env "host" and plan_priority "override" Then the resolved execution environment should be "host" -# @tdd_issue @tdd_issue_4290 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4290 Scenario: Project override wins over devcontainer (Level 2 beats Level 3) Given a tool runner with a devcontainer-instance linked resource When I execute the tool with project_env "host" and project_priority "override" Then the resolved execution environment should be "host" -# @tdd_issue @tdd_issue_4290 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4290 Scenario: Devcontainer wins over plan fallback (Level 3 beats Level 4) Given a tool runner with a devcontainer-instance linked resource When I execute the tool with plan_env "host" and plan_priority "fallback" Then the resolved execution environment should be "container" -# @tdd_issue @tdd_issue_4290 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4290 Scenario: Devcontainer wins over project fallback (Level 3 beats Level 5) Given a tool runner with a devcontainer-instance linked resource When I execute the tool with project_env "host" and project_priority "fallback" Then the resolved execution environment should be "container" -# @tdd_issue @tdd_issue_4290 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4290 Scenario: Plan fallback used when no devcontainer (Level 4) Given a tool runner with no linked resources When I execute the tool with plan_env "container" and plan_priority "fallback" Then the resolved execution environment should be "container" -# @tdd_issue @tdd_issue_4290 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4290 Scenario: Project fallback used when no devcontainer and no plan env (Level 5) Given a tool runner with no linked resources When I execute the tool with project_env "container" and project_priority "fallback" Then the resolved execution environment should be "container" -# @tdd_issue @tdd_issue_4290 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4290 Scenario: Host default when nothing configured (Level 6) Given a tool runner with no linked resources When I execute the tool with no environment configuration Then the resolved execution environment should be "host" -# @tdd_issue @tdd_issue_4290 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4290 Scenario: Plan override beats project override (Level 1 beats Level 2) Given a tool runner with no linked resources When I execute the tool with plan_env "host" plan_priority "override" project_env "container" project_priority "override" @@ -65,31 +56,27 @@ Feature: TDD Issue #2592 — ToolRunner.execute() 6-level execution environment # ── Integration tests: override vs fallback scenarios ── -# @tdd_issue @tdd_issue_4290 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4290 Scenario: Override bypasses devcontainer auto-detection Given a tool runner with a devcontainer-instance linked resource When I execute the tool with plan_env "host" and plan_priority "override" Then the resolved execution environment should be "host" And the devcontainer was not used -# @tdd_issue @tdd_issue_4290 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4290 Scenario: Fallback defers to devcontainer when present Given a tool runner with a devcontainer-instance linked resource When I execute the tool with plan_env "host" and plan_priority "fallback" Then the resolved execution environment should be "container" And the devcontainer was used -# @tdd_issue @tdd_issue_4290 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4290 Scenario: Fallback uses configured env when no devcontainer present Given a tool runner with no linked resources When I execute the tool with plan_env "host" and plan_priority "fallback" Then the resolved execution environment should be "host" -# @tdd_issue @tdd_issue_4290 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4290 Scenario: Default priority is fallback — devcontainer wins over unconfigured plan env Given a tool runner with a devcontainer-instance linked resource When I execute the tool with plan_env "host" and no explicit priority diff --git a/features/testing/tdd_expected_fail_demo.feature b/features/testing/tdd_expected_fail_demo.feature index 60499d58a..3ae4d919e 100644 --- a/features/testing/tdd_expected_fail_demo.feature +++ b/features/testing/tdd_expected_fail_demo.feature @@ -12,8 +12,7 @@ Feature: TDD expected-fail result inversion demo tested via mock-based unit tests in tdd_tag_validation.feature and via real Scenario objects in tdd_expected_fail_infrastructure.feature. -# @tdd_issue @tdd_issue_999 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_999 @tdd_expected_fail Scenario: Demo bug 999 expected failure is inverted to pass Given tdd demo a step that always succeeds When tdd demo a deliberately failing assertion is executed diff --git a/features/tls_certificate_check.feature b/features/tls_certificate_check.feature index e97b58366..df729e680 100644 --- a/features/tls_certificate_check.feature +++ b/features/tls_certificate_check.feature @@ -10,8 +10,7 @@ Feature: TLS certificate health-check script # (SANs). The scenarios below verify that the check script correctly # detects this condition and reports it as an error. -# @tdd_issue @tdd_issue_1543 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_1543 Scenario: Script detects missing SAN for git.dev.cleveragents.com Given a TLS certificate for "git.cleverthis.com" with SANs "git.cleverthis.com,git.cleveragents.com" And the certificate expires in 90 days @@ -19,16 +18,14 @@ Feature: TLS certificate health-check script Then the check result should be a failure And the check error should mention "not found in certificate SANs" -# @tdd_issue @tdd_issue_1543 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_1543 Scenario: Script passes when hostname is present in SANs Given a TLS certificate for "git.cleverthis.com" with SANs "git.cleverthis.com,git.dev.cleveragents.com" And the certificate expires in 90 days When the TLS check runs for hostname "git.dev.cleveragents.com" Then the check result should be a success -# @tdd_issue @tdd_issue_1543 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_1543 Scenario: Script detects expired certificate Given a TLS certificate for "git.cleverthis.com" with SANs "git.cleverthis.com,git.dev.cleveragents.com" And the certificate expired 5 days ago @@ -36,8 +33,7 @@ Feature: TLS certificate health-check script Then the check result should be a failure And the check error should mention "expired" -# @tdd_issue @tdd_issue_1543 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_1543 Scenario: Script warns when certificate expires within threshold Given a TLS certificate for "git.cleverthis.com" with SANs "git.cleverthis.com,git.dev.cleveragents.com" And the certificate expires in 15 days @@ -45,8 +41,7 @@ Feature: TLS certificate health-check script Then the check result should be a success And the check warning should mention "expires in" -# @tdd_issue @tdd_issue_1543 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_1543 Scenario: Script does not warn when certificate expires beyond threshold Given a TLS certificate for "git.cleverthis.com" with SANs "git.cleverthis.com,git.dev.cleveragents.com" And the certificate expires in 60 days @@ -54,24 +49,21 @@ Feature: TLS certificate health-check script Then the check result should be a success And the check has no warnings -# @tdd_issue @tdd_issue_1543 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_1543 Scenario: Script reports TLS handshake failure as an error Given the TLS connection raises an SSLError "CERTIFICATE_VERIFY_FAILED" When the TLS check runs for hostname "git.dev.cleveragents.com" Then the check result should be a failure And the check error should mention "TLS" -# @tdd_issue @tdd_issue_1543 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_1543 Scenario: Script reports connection timeout as an error Given the TLS connection times out When the TLS check runs for hostname "git.dev.cleveragents.com" Then the check result should be a failure And the check error should mention "timed out" -# @tdd_issue @tdd_issue_1543 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_1543 Scenario: Script reports connection refused as an error Given the TLS connection is refused When the TLS check runs for hostname "git.dev.cleveragents.com" @@ -80,16 +72,14 @@ Feature: TLS certificate health-check script # ── Wildcard SAN matching ────────────────────────────────────────────── -# @tdd_issue @tdd_issue_1543 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_1543 Scenario: Script accepts wildcard SAN matching the hostname Given a TLS certificate for "git.cleverthis.com" with SANs "*.cleverthis.com" And the certificate expires in 90 days When the TLS check runs for hostname "git.cleverthis.com" Then the check result should be a success -# @tdd_issue @tdd_issue_1543 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_1543 Scenario: Script rejects wildcard SAN that does not match the hostname Given a TLS certificate for "git.cleverthis.com" with SANs "*.cleveragents.com" And the certificate expires in 90 days @@ -99,26 +89,22 @@ Feature: TLS certificate health-check script # ── Helper function unit tests ───────────────────────────────────────── -# @tdd_issue @tdd_issue_1543 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_1543 Scenario: _hostname_matches_san returns True for exact match When I check if hostname "git.dev.cleveragents.com" matches SANs "git.dev.cleveragents.com,git.cleveragents.com" Then the SAN match result should be True -# @tdd_issue @tdd_issue_1543 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_1543 Scenario: _hostname_matches_san returns False when hostname is absent When I check if hostname "git.dev.cleveragents.com" matches SANs "git.cleveragents.com,git.cleverthis.com" Then the SAN match result should be False -# @tdd_issue @tdd_issue_1543 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_1543 Scenario: _hostname_matches_san handles wildcard SANs correctly When I check if hostname "git.cleverthis.com" matches SANs "*.cleverthis.com" Then the SAN match result should be True -# @tdd_issue @tdd_issue_1543 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_1543 Scenario: _hostname_matches_san rejects multi-level wildcard When I check if hostname "a.b.cleverthis.com" matches SANs "*.cleverthis.com" Then the SAN match result should be False diff --git a/features/tool_wrapping_runtime.feature b/features/tool_wrapping_runtime.feature index 861c70018..4e0559d54 100644 --- a/features/tool_wrapping_runtime.feature +++ b/features/tool_wrapping_runtime.feature @@ -207,16 +207,14 @@ Feature: Tool wrapping runtime When I call resolve_execution_environment on the runner Then the resolved environment should be local -# @tdd_issue @tdd_issue_4292 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4292 @tdd_expected_fail Scenario: ToolRunner execute returns error when env resolver raises ValueError Given a ToolRunner with a value-error-raising env resolver When I execute a tool through the runner with env error Then the tool result should have success false And the tool result error should contain "Execution environment error" -# @tdd_issue @tdd_issue_4292 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4292 @tdd_expected_fail Scenario: ToolRunner execute returns error for container environment Given a ToolRunner with a container-returning env resolver When I execute a tool through the runner with container env diff --git a/features/tui_session_export_import.feature b/features/tui_session_export_import.feature index 5ce6b212a..c1599b3d8 100644 --- a/features/tui_session_export_import.feature +++ b/features/tui_session_export_import.feature @@ -52,8 +52,7 @@ Feature: TUI session export/import (JSON + Markdown) And the exported markdown file should exist And the exported markdown file should contain "# Session:" -# @tdd_issue @tdd_issue_4293 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4293 @tdd_expected_fail Scenario: Export session as JSON (default format) Given there is a mocked session for markdown export When I run session CLI export with no format flag diff --git a/features/tui_slash_command_overlay_coverage.feature b/features/tui_slash_command_overlay_coverage.feature index 7164324c5..7d245cc88 100644 --- a/features/tui_slash_command_overlay_coverage.feature +++ b/features/tui_slash_command_overlay_coverage.feature @@ -48,8 +48,7 @@ Feature: TUI Slash Command Overlay Coverage Then the fallback class should be usable as a standalone object And calling update on the fallback instance should store the text -# @tdd_issue @tdd_issue_4294 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4294 @tdd_expected_fail Scenario: set_commands renders descriptions alongside command names Given I have a SlashCommandOverlay instance When I call set_commands with query "" and commands "session:create,session:list" diff --git a/features/tui_slash_overlay_descriptions.feature b/features/tui_slash_overlay_descriptions.feature index eaf15d28a..64119cd2f 100644 --- a/features/tui_slash_overlay_descriptions.feature +++ b/features/tui_slash_overlay_descriptions.feature @@ -5,8 +5,7 @@ Feature: TUI Slash Command Overlay Shows Descriptions Background: Given the slash command overlay module is imported -# @tdd_issue @tdd_issue_4295 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4295 @tdd_expected_fail Scenario: Overlay renders command name and description in aligned columns Given I have a SlashCommandOverlay instance When I call set_commands with query "" and commands "session:create,settings" @@ -24,8 +23,7 @@ Feature: TUI Slash Command Overlay Shows Descriptions And the overlay text should contain "Desc for session:list" And the overlay text should not contain " /plan:use" -# @tdd_issue @tdd_issue_4295 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4295 @tdd_expected_fail Scenario: Overlay uses real slash_command_specs from catalog Given I have a SlashCommandOverlay instance When I initialise the overlay with real slash command specs @@ -34,8 +32,7 @@ Feature: TUI Slash Command Overlay Shows Descriptions And the overlay text should contain " /settings" And the overlay text should contain "Open settings" -# @tdd_issue @tdd_issue_4371 @tdd_expected_fail @skip - @skip + @tdd_issue @tdd_issue_4371 @tdd_expected_fail Scenario: TDD capture - overlay previously showed names only without descriptions Given I have a SlashCommandOverlay instance When I initialise the overlay with real slash command specs diff --git a/noxfile.py b/noxfile.py index f8bfa4ec9..4a3cca99f 100644 --- a/noxfile.py +++ b/noxfile.py @@ -178,7 +178,6 @@ def unit_tests(session: nox.Session): args = [ behave_cmd, "-q", - "--tags=not @skip", *parallel_args, *session.posargs, ] @@ -186,7 +185,6 @@ def unit_tests(session: nox.Session): args = [ behave_cmd, "-q", - "--tags=not @skip", *parallel_args, "features/", *session.posargs, @@ -568,7 +566,6 @@ def coverage_report(session: nox.Session): behave_args = [ behave_cmd, "-q", - "--tags=not @skip", "--no-capture", *session.posargs, ] @@ -576,7 +573,6 @@ def coverage_report(session: nox.Session): behave_args = [ behave_cmd, "-q", - "--tags=not @skip", "--no-capture", "features/", *session.posargs,