cleveragents-core/features/database_models_coverage_r2.feature

Feature: Database models coverage round 2
  Additional Behave scenarios targeting uncovered lines in
  src/cleveragents/infrastructure/database/models.py identified
  from build/coverage.xml.

  # ---------------------------------------------------------------
  # LifecycleActionModel — safety_profile round-trip (lines 376, 427)
  # ---------------------------------------------------------------

  Scenario: LifecycleActionModel to_domain deserializes safety_profile_json
    Given a LifecycleActionModel with safety_profile_json populated
    When I convert the action model to domain via to_domain
    Then the domain action has a non-null safety_profile object

  Scenario: LifecycleActionModel from_domain serializes safety_profile
    Given an Action domain object with a SafetyProfile attached
    When I convert the action to a model via from_domain
    Then the model safety_profile_json contains serialized SafetyProfile data

  # ---------------------------------------------------------------
  # LifecycleActionModel — string arg_type/requirement (lines 466, 469)
  # ---------------------------------------------------------------

  Scenario: LifecycleActionModel from_domain with plain-string arg_type and requirement
    Given an Action domain object whose arguments have plain-string arg_type and requirement
    When I convert that action to a model via from_domain
    Then the model argument rows use the plain-string values directly

  # ---------------------------------------------------------------
  # LifecyclePlanModel — string processing_state (line 882)
  # ---------------------------------------------------------------

#   @tdd_issue @tdd_issue_4245 @tdd_expected_fail @skip
  @skip
  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
    Then the model processing_state equals the plain string value

  # ---------------------------------------------------------------
  # LifecyclePlanModel — automation_profile serialization (line 890)
  # ---------------------------------------------------------------

#   @tdd_issue @tdd_issue_4245 @tdd_expected_fail @skip
  @skip
  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
    Then the model automation_profile column contains JSON with profile_name

  # ---------------------------------------------------------------
  # LifecyclePlanModel — fallback namespace (line 906)
  # ---------------------------------------------------------------

#   @tdd_issue @tdd_issue_4245 @tdd_expected_fail @skip
  @skip
  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
    Then the model namespace equals "local"

  # ---------------------------------------------------------------
  # LifecyclePlanModel — error_details serialization (line 923)
  # ---------------------------------------------------------------

#   @tdd_issue @tdd_issue_4245 @tdd_expected_fail @skip
  @skip
  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
    Then the model error_details_json is a JSON string of the details dict

  # ---------------------------------------------------------------
  # SkillModel — include with overrides (line 2327)
  # ---------------------------------------------------------------

  Scenario: SkillModel from_domain persists include overrides
    Given a Skill domain object with an include that has overrides
    When I convert the skill to a model via from_domain
    Then the include item_config contains the serialized overrides

  # ---------------------------------------------------------------
  # DecisionModel — string decision_type fallback (line 2698)
  # ---------------------------------------------------------------

  Scenario: DecisionModel from_domain with plain-string decision_type
    Given a Decision domain object whose decision_type is a plain string
    When I convert the decision to a model via from_domain
    Then the model decision_type equals the plain string

  # ---------------------------------------------------------------
  # CheckpointModel — to_domain full path (lines 2823-2852)
  # ---------------------------------------------------------------

  Scenario: CheckpointModel to_domain converts all fields including metadata
    Given a CheckpointModel with metadata_json containing reason and phase
    When I convert the checkpoint model to domain via to_domain
    Then the domain checkpoint has the correct metadata fields

  Scenario: CheckpointModel to_domain handles invalid metadata_json gracefully
    Given a CheckpointModel with invalid JSON in metadata_json
    When I convert the checkpoint model to domain via to_domain
    Then the domain checkpoint metadata is empty defaults

  # ---------------------------------------------------------------
  # CheckpointModel — from_domain full path (lines 2865-2879)
  # ---------------------------------------------------------------

  Scenario: CheckpointModel from_domain serializes all checkpoint fields
    Given a Checkpoint domain object with full metadata
    When I convert the checkpoint to a model via from_domain
    Then the model has correct checkpoint_id plan_id and metadata_json

  # ---------------------------------------------------------------
  # get_session function (lines 2907-2908)
  # ---------------------------------------------------------------

  Scenario: get_session returns a usable SQLAlchemy session
    Given an in-memory SQLAlchemy engine
    When I call get_session with that engine
    Then I receive a valid SQLAlchemy session object