diff --git a/features/steps/tdd_context_tier_runtime_steps.py b/features/steps/tdd_context_tier_runtime_steps.py
index 3c2bfb769..518532fc3 100644
--- a/features/steps/tdd_context_tier_runtime_steps.py
+++ b/features/steps/tdd_context_tier_runtime_steps.py
@@ -4,20 +4,10 @@ These steps exercise ``ContextTierService`` and verify that it automatically
 promotes fragments on repeated access, demotes stale fragments, and evicts
 fragments when the hot tier budget overflows.
 
-On ``master`` (before the fix), ``ContextTierService`` has data models and
-manual ``promote()``/``demote()``/``evict_lru()`` methods but NO automatic
-runtime logic:
-
-- ``get()`` updates ``access_count`` and ``last_accessed`` but never
-  auto-promotes a heavily accessed cold/warm fragment.
-- There is no staleness enforcement: no method inspects ``last_accessed``
-  timestamps and auto-demotes stale hot fragments.
-- ``store()`` does not enforce ``TierBudget.max_tokens_hot``: storing
-  beyond the budget does not trigger automatic LRU eviction.
-
-The assertions in these steps will **fail** until the bug is fixed,
-proving the bug exists.  The ``@tdd_expected_fail`` tag inverts the
-result so CI passes.
+Bug #821 identified that ``ContextTierService`` had data models and manual
+``promote()``/``demote()``/``evict_lru()`` methods but NO automatic runtime
+logic.  The bug has been fixed — these tests now serve as a permanent
+regression guard confirming the runtime logic works correctly.
 """
 
 from __future__ import annotations
diff --git a/features/tdd_context_tier_runtime.feature b/features/tdd_context_tier_runtime.feature
index 091bcc1fb..3038defb4 100644
--- a/features/tdd_context_tier_runtime.feature
+++ b/features/tdd_context_tier_runtime.feature
@@ -5,20 +5,16 @@ Feature: TDD Issue #821 — context tier service has data models but no runtime
   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:
+  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:
 
-  - 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.
+  - 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 assert the expected runtime behaviour and will FAIL until
-  the bug is fixed.  The @tdd_expected_fail tag inverts the result so
-  CI passes.
+  These tests serve as a permanent regression guard for the fix.
 
   Scenario: Promotion on repeated access moves fragment to a higher tier
     Given a context tier service with default budget