From 2c69496b96fc30d4f98588653d1481ea4b517eea Mon Sep 17 00:00:00 2001 From: Yujong Lee Date: Fri, 30 Oct 2026 08:20:43 -0700 Subject: [PATCH] docs(skills): inline redis-access migration order Co-Authored-By: Claude Opus 5.5 --- .agents/skills/redis-access/SKILL.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.agents/skills/redis-access/SKILL.md b/.agents/skills/redis-access/SKILL.md index 5859806081c..9e8b319b56c 100644 --- a/.agents/skills/redis-access/SKILL.md +++ b/.agents/skills/redis-access/SKILL.md @@ -157,7 +157,7 @@ class NativeLockStore: ## Scope -- The milestone order for the migration, and what each PR may and may not touch, is in `references/migration-plan.md`. The first two milestones are Python only and ship first. Nothing under `litellm-rust/` changes until milestone 2 has merged +- Python moves ship first. Every raw redis-py keyspace outside `litellm/caching/` goes behind a store on the transport before anything under `litellm-rust/` changes for Redis. The first Rust port is the pod lock keyspace, since it is low traffic and its owner-checked release proves both stacks write the same `json.dumps` encoded owner - A keyspace moves whole in one commit, every operation the caller runs on those keys. Moving the read and leaving the write on `RedisCache` is not a move - Do only what was asked. An extraction is not a store move, a store move is not a Rust port, and a Rust port of one keyspace does not switch another - A Rust store that already exists does not by itself justify switching its Python caller. Switching callers is its own change with live verification