forked from cleveragents/cleveragents-core
brent.edwards
202c9bfe75
## Summary TDD expected-fail tests proving bug #821 exists: `ContextTierService` has data models for hot/warm/cold tiers but **no runtime logic** for automatic promotion, demotion, or eviction. - **Promotion on access**: Accessing a cold-tier fragment repeatedly via `get()` does NOT auto-promote it — `get()` updates `access_count`/`last_accessed` but never calls `promote()` - **Demotion on staleness**: No staleness enforcement method exists — tried `enforce_staleness()`, `apply_tier_policy()`, `tick()`, etc. — none are implemented - **Eviction on budget overflow**: `store()` does NOT enforce `TierBudget.max_tokens_hot` — the hot tier grows without bound ### Files Added | File | Purpose | |------|---------| | `features/tdd_context_tier_runtime.feature` | 3 Behave scenarios tagged `@tdd_expected_fail @tdd_bug @tdd_bug_821 @mock_only` | | `features/steps/tdd_context_tier_runtime_steps.py` | Type-annotated step definitions exercising real `ContextTierService` | | `robot/tdd_context_tier_runtime.robot` | 3 Robot Framework integration tests tagged `tdd_expected_fail` | | `robot/helper_tdd_context_tier_runtime.py` | Helper script for Robot tests with 3 subcommands | ### Verification - `nox -s lint` — passed - `nox -s typecheck` — passed (0 errors) - `nox -s unit_tests -- features/tdd_context_tier_runtime.feature` — **3 scenarios passed** (all assertions fail as expected, `@tdd_expected_fail` inverts to CI pass) ISSUES CLOSED: #840 Reviewed-on: cleveragents/cleveragents-core#1058 Co-authored-by: Brent Edwards <brent.edwards@cleverthis.com> Co-committed-by: Brent Edwards <brent.edwards@cleverthis.com>
40 lines
2.0 KiB
Gherkin
40 lines
2.0 KiB
Gherkin
@tdd_expected_fail @tdd_bug @tdd_bug_821 @mock_only
|
|
Feature: TDD Bug #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
|
|
|
|
ContextTierService has well-defined data models for hot/warm/cold tiers
|
|
(ContextTier, TieredFragment, TierBudget) and manual promote()/demote()/
|
|
evict_lru() methods, but NO automatic runtime logic:
|
|
|
|
- get() touches access metadata but never auto-promotes a frequently
|
|
accessed cold/warm fragment to a higher tier.
|
|
- There is no staleness enforcement: no method checks last_accessed
|
|
timestamps and demotes stale hot fragments to warm/cold.
|
|
- store() does not enforce budget limits: storing beyond
|
|
max_tokens_hot does not trigger automatic eviction.
|
|
|
|
These tests assert the expected runtime behaviour and will FAIL until
|
|
the bug is fixed. The @tdd_expected_fail tag inverts the result so
|
|
CI passes.
|
|
|
|
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
|
|
|
|
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
|
|
|
|
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
|