cache: define response cache boundaries

TASKS.md

@@ -33,6 +33,11 @@ Implementation slices:
    - managed Cloud default
    - enterprise optional cluster-aware deployment
 5. Протянуть capability/config model так, чтобы решение "использовать или нет внешний cache" принимал оператор, а не кодовая база.
+6. Зафиксировать safe cache boundaries:
+   - platform cache и response cache не смешиваются;
+   - ключи response cache изолируются минимум по `workspace + agent + operation + request fingerprint`;
+   - ключи coordination state изолируются минимум по `workspace + agent + cache scope`;
+   - при отсутствии внешнего cache все эти контуры продолжают работать через in-memory fallback.
 
 DoD:
 - без `Valkey/Redis` Community и self-hosted deployment остаются рабочими;
@@ -40,6 +45,7 @@ DoD:
 - `Cloud` может использовать shared cache layer по умолчанию;
 - `Enterprise` может подключать cache layer на своей инфраструктуре, включая кластерный вариант;
 - runtime/docs/manifests не делают cache обязательным для базового запуска.
+- cache boundaries и key namespaces документированы так, чтобы разные агенты и рабочие области не пересекались друг с другом.
 
 Verification:
 - targeted runtime/admin/mcp tests for cache contracts and fallback mode;
@@ -53,8 +59,12 @@ Progress:
   - Community deployment manifest now includes optional `valkey` profile and cache env wiring without making cache mandatory
   - shared `Valkey/Redis` backend layer now exists in `crank-runtime` with config-driven store factory for managed / enterprise contours
   - admin-api and mcp-server ingress rate limiting now use shared external cache state when `CRANK_CACHE_BACKEND` is `valkey` or `redis`
+  - `ExecutionConfig.response_cache` is now part of the public operation model, and `admin-api` validates the safe Community baseline: only explicit `REST GET` operations without `auth_profile_ref`
+  - cache boundary and namespace rules are now documented for `platform / coordination cache` versus `response cache`
 - pending:
-  - wire response cache / replay guard / coordination state into additional concrete runtime and transport paths
+  - preserve strict cache isolation between workspace/agent/operation scopes while wiring concrete cache-key builders into runtime hot paths
+  - wire actual response cache reads/writes into concrete runtime execution paths
+  - wire replay guard / coordination state into additional concrete runtime and transport paths
 
 ## Planned