cache: define response cache boundaries

docs/runtime-config.md

@@ -166,6 +166,42 @@ Demo/deployment:
 - `CRANK_CACHE_BACKEND=valkey` или `redis` при наличии внешнего cache store;
 - без этих переменных система должна оставаться полностью работоспособной.
 
+### Cache boundaries
+
+В платформе должны существовать два разных cache-контура:
+
+- `platform / coordination cache`
+- `response cache`
+
+Первый контур хранит служебное краткоживущее состояние:
+
+- ingress rate limiting;
+- replay guard;
+- ephemeral coordination state;
+- будущие short-lived / one-time token helpers.
+
+Второй контур хранит только кэшируемые ответы операций.
+
+Эти контуры не должны смешивать ключи друг с другом.
+
+### Cache key isolation
+
+Базовое правило изоляции:
+
+- разные `workspace` не должны делить одни и те же cache keys;
+- разные `agent` внутри одного `workspace` тоже не должны делить одни и те же response cache keys по умолчанию;
+- разные `operation` внутри одного `agent` не должны попадать в общий response cache namespace.
+
+Стартовая модель namespace для response cache:
+
+- `workspace + agent + operation + request fingerprint`
+
+Стартовая модель namespace для platform / coordination cache:
+
+- `workspace + agent + cache scope + logical key`
+
+Это позволяет безопасно использовать один внешний `Valkey/Redis` сразу для нескольких агентов и рабочих областей без взаимного пересечения данных.
+
 ### Auth env
 
 Для app-level auth нужны: