@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,
  and evicts fragments based on access patterns, staleness, and budget limits
  So that the bug is captured and will be caught by a regression test

  Bug #821 identified that ContextTierService had data models for
  hot/warm/cold tiers (ContextTier, TieredFragment, TierBudget) and
  manual promote()/demote()/evict_lru() methods, but NO automatic
  runtime logic.  The bug has been fixed — ContextTierService now:

  - auto-promotes frequently accessed cold/warm fragments to a higher tier,
  - enforces staleness by demoting stale hot fragments to warm/cold,
  - enforces budget limits by evicting on hot tier overflow.

  These tests serve as a permanent regression guard for the fix.

  @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
  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
  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
    When I store one more fragment in the hot tier
    Then the oldest fragment should have been evicted from the hot tier