@coverage_boost
Feature: System diagnostics uncovered code paths
  As a developer ensuring thorough test coverage
  I want to exercise uncovered diagnostic check paths in system.py
  So that stale-lock, async-worker, error-pattern, and file-permission edge cases are tested

  # ===========================================================================
  # _check_file_permissions — line 344: writable-but-not-readable data dir
  # ===========================================================================

  Scenario: File permissions check on data dir that is writable but not readable
    Given a sysdiag test environment
    And a data dir that exists
    When I run the file permissions check with read access denied
    Then the sysdiag check status should be "warn"
    And the sysdiag check details should be "data dir w"

  Scenario: File permissions check on data dir that is neither readable nor writable
    Given a sysdiag test environment
    And a data dir that exists
    When I run the file permissions check with no access at all
    Then the sysdiag check status should be "error"
    And the sysdiag check details should be "data dir no access"

  # ===========================================================================
  # _check_stale_locks — lines 367-388
  # ===========================================================================

  Scenario: Stale locks check finds zero stale locks in existing table
    Given a sysdiag test environment
    When I run the stale locks check with 0 stale locks in the table
    Then the sysdiag check status should be "ok"
    And the sysdiag check details should be "0 stale locks"

  Scenario: Stale locks check finds stale locks present
    Given a sysdiag test environment
    When I run the stale locks check with 3 stale locks in the table
    Then the sysdiag check status should be "warn"
    And the sysdiag check details should contain "3 stale lock(s) found"
    And the sysdiag check should have a recommendation

  Scenario: Stale locks check handles database errors gracefully
    Given a sysdiag test environment
    When I run the stale locks check with a database error
    Then the sysdiag check status should be "warn"
    And the sysdiag check details should be "unable to check"

  # ===========================================================================
  # _check_async_worker_health — lines 405-417
  # ===========================================================================

  Scenario: Async worker health check when async is enabled
    Given a sysdiag test environment
    When I run the async worker health check with async enabled
    Then the sysdiag check status should be "ok"
    And the sysdiag check details should contain "enabled"
    And the sysdiag check details should contain "max_workers="
    And the sysdiag check details should contain "poll_interval="

  Scenario: Async worker health check handles settings errors gracefully
    Given a sysdiag test environment
    When I run the async worker health check with a settings error
    Then the sysdiag check status should be "warn"
    And the sysdiag check details should be "unable to check"

  # ===========================================================================
  # _check_error_patterns — lines 438-442
  # ===========================================================================

  Scenario: Error pattern check when service initialization fails
    Given a sysdiag test environment
    When I run the error patterns check with a service error
    Then the sysdiag check status should be "ok"
    And the sysdiag check details should be "empty (no patterns recorded)"