Jev via LiteLLM: shadow on own virtual key, Jev decides trend classification

Two items Isidro approved on 2026-09-27 (Jev panel).

"sombras" (HIGH). The Jev shadow on the trend classifier called TypeSafe or OpenRouter directly, skipping LiteLLM's PII scrubber and leaving its spend without an owner. It now goes through LiteLLM's jev model group with its own virtual key, CMO_JEV_LITELLM_KEY (alias agent-cmoagent-jev, tag agent:cmoagent-jev, model jev only, $1/30d, rpm 300; 1Password: "LiteLLM VK CMOAgent Jev"). The theme question gains a none option.

"cmo" (LOW). Jev now makes the watcher's classification: one request per item with the five independent questions (theme, platform, language as Choice; priority, sentiment as Score). Haiku decides only if the Jev call fails, and that is logged (watcher.jev_failed) and written to runtime/jev-trend-decisions.jsonl. CMO_JEV_PRIMARY=0 reverts to Haiku without a code change.

Shadow week (19-26 Sep, 370 items, Haiku vs Jev): theme agreement 52 %, platform 75 %, priority within ±2 68 %. Jev scores priority lower (mean 3.5 vs 5.35). Items at priority 7 or higher drop from 96 to 15, so the watcher's high-priority list will be much shorter. Latency p50 375 ms, total cost $0.011.

Live check against LiteLLM (50 shadow titles): 50/50 decided by Jev, p50 308 ms, $0.0019. 29 of 50 came back as none, mostly player chatter and beginner questions from Reddit, with low priority. They are still persisted, but no longer feed the art-director theme buckets.

Test plan

• uv run python -m pytest tests/ (1322 passed, coverage 77.24 %)
• ruff, mypy
• live call through LiteLLM with the new key; fallback path exercised on a real 429
• after merge: regenerate .env, rebuild the watcher container, check the first run in jev-trend-decisions.jsonl