Feature: Database Integration with Unit of Work and Repositories
  As a developer
  I want to ensure database operations work correctly
  So that data is persisted reliably

  Background:
    Given I have a clean test database
    And I have initialized the Unit of Work

  Scenario: Create and retrieve a project using repository
    When I create a project with name "test-project"
    Then the project should be saved in the database
    And I can retrieve the project using Unit of Work
    And the project should have the correct properties

  Scenario: Unit of Work commits all changes together
    When I start a Unit of Work transaction
    And I create a project "test-project" in the transaction
    And I create a plan "test-plan" in the transaction
    And I commit the transaction
    Then both the project and plan should exist in the database

  Scenario: Unit of Work rollback on error
    When I start a Unit of Work transaction
    And I create a project "test-project" in the transaction
    And an error occurs during the transaction
    Then the transaction should rollback
    And no data should be saved to the database

  Scenario: Repository pattern for plans
    Given I have a project "test-project" in the database
    When I create a plan "feature-1" for the project
    And I create another plan "feature-2" for the project
    Then I should be able to list all plans for the project
    And I should be able to set "feature-2" as the current plan
    And the current plan should be "feature-2"

  Scenario: Context repository operations
    Given I have a project with a current plan
    When I add a file "test.py" to the context
    And I add another file "main.py" to the context
    Then I should be able to list all context files
    And I should be able to remove "test.py" from context
    And only "main.py" should remain in context

  Scenario: Change repository tracks modifications
    Given I have a project with a built plan
    When I add a change to create "new_file.py"
    And I add a change to modify "existing.py"
    And I mark the first change as applied
    Then the applied change should have an applied timestamp
    And the second change should still be pending

  Scenario: Service uses Unit of Work for transactions
    When I use ProjectService to initialize a project
    Then the service should use Unit of Work
    And the database infrastructure should be initialized
    And the project should be persisted correctly

  Scenario: PlanService uses repositories
    Given I have an initialized project for database testing
    When I use PlanService to create a plan
    Then the plan should be saved via repository
    And the plan should be set as current
    And I should be able to retrieve it

  Scenario: ContextService uses repositories
    Given I have a project with a plan
    When I use ContextService to add files
    Then the context should be saved via repository
    And the files should be associated with the plan
    And I should be able to query the context

  Scenario: Unit of Work auto-migrates database on first access
    Given I have a unit of work without initialization for "sqlite:///:memory:"
    When I open a transaction which should auto-run migrations
    Then the migration runner should be invoked once with confirmation