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 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 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 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 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