deploy: deblocage deepseek-v4.1-flash whitelist 4 niveaux (infra-2026-09-040)

_INDEX.md

@@ -85,6 +85,7 @@
 
 | Runbook | Date | Tags |
 |---------|------|------|
+| [Déblocage DeepSeek V4.1 Flash — whitelist à 4 niveaux (Bifrost provider+VK, catalogues locaux DSH/opencode-natif/openclaw-perso), Hermes déjà débloqué sans whitelist locale ; bonus : baseURL DSH corrigé (ne dépendait plus du relais NAS) (ticket infra-2026-09-040)](common/deepseek-v41-flash-deblocage-whitelist-multiniveaux-20260911.md) | 2026-09-11 | infra, bifrost, opencode-go, deepseek, dsh, openclaw-perso, hermes, virtual-key |
 | [Correctif routage Bifrost -> OpenCode Go (base_url casse sur un residu de sidecar abandonne, chemin /zen/go sans /v1) + raccordement hermes-tt/hermes-nabil/DSH au pattern bifrost-proxy (creation vk-hermes-nabil, cloture volet routage du ticket infra-2026-09-023)](common/bifrost-opencode-routing-fix-20260907.md) | 2026-09-07 | infra, bifrost, opencode-go, hermes-tt, hermes-nabil, dsh, virtual-key, routing |
 | [Piège clé virtuelle Nabil-Key (bfk-0cd1fb...) vs clés dédiées Hermes : fuite budgétaire 8 $/mois, audit exhaustif (perso/tt/nyora), correction chirurgicale vision perso, et tests d'inférence réels (ticket infra-2026-09-014)](common/piege-virtual-key-nabil-key-bifrost-hermes-20260904.md) | 2026-09-04 | infra, bifrost, virtual-key, nabil-key, budget, hermes, audit, gemini |
 | [Passerelle MCP dédiée NyoraNotes (multi-agent, StreamableHTTP port 3098, scoping strict par dossier, connecteur DSH validé)](common/nyora-notes-mcp-gateway-deploiement-20260826.md) | 2026-08-26 | nyora-notes-mcp, mcp, streamable-http, scoping, dsh, tailscale |

common/deepseek-v41-flash-deblocage-whitelist-multiniveaux-20260911.md

@@ -0,0 +1,96 @@
+# Déblocage DeepSeek V4.1 Flash — whitelist à plusieurs niveaux (11/09/2026)
+
+Ticket : infra-2026-09-040 (clôturé définitif par Claude)
+
+## Contexte
+
+DeepSeek V4.1 Flash sorti le 10/09/2026 (remplace V4 Flash chez DeepSeek, prix
+Flash reduits ~11-57%). Sur OpenCode Go (abonnement $10/mois deja utilise par
+Bifrost), ce modele beneficie en plus d'un boost temporaire x4 sur les limites
+d'usage. Nabil a signale ne pas pouvoir en profiter, ni des modeles gratuits
+OpenRouter, sur aucun de ses assistants (Hermes NAS/VPS, openclaw-perso, DSH,
+OpenCode CLI natif VPS).
+
+## Diagnostic
+
+Le blocage n'etait PAS un manque d'acces reseau/abonnement : le modele est
+immediatement disponible sur le catalogue OpenCode Go (`GET /zen/go/v1/models`)
+et testable en direct avec la cle deja en place. Les modeles gratuits
+OpenRouter sont eux aussi deja largement whitelistes cote Bifrost pour la
+plupart des VK (Gemma, Nemotron, GPT-OSS, Qwen3-coder, GLM-4.5-air, etc.).
+
+Le vrai frein est une architecture a **quatre niveaux de whitelist**, aucun
+avec hot-reload, qui doivent tous autoriser un modele avant qu'un agent donne
+puisse reellement l'appeler :
+
+1. Catalogue du provider OpenCode Go lui-meme (pas un blocage ici, juste la
+   source de verite sur les IDs de modele reels).
+2. Bifrost — whitelist au niveau de la cle provider (`config.json`,
+   `providers.opencode.keys[0].models`).
+3. Bifrost — whitelist par VK (`governance_virtual_key_provider_configs.allowed_models`,
+   une par (VK, provider) en base SQLite `config.db`) ; necessite un restart de
+   Bifrost pour etre relue (pas de hot-reload SQL).
+4. Catalogue local fige de chaque agent, quand il en a un : container `opencode`
+   natif VPS (`opencode.json`), DSH (`settings.yaml`, providers `bifrost` +
+   `opencode-direct`, tous deux avec liste de modeles en dur), openclaw-perso
+   (`openclaw.json`, `models.providers.bifrost.models` + `agents.defaults.models`).
+   Hermes (tt/nyora/perso/nabil) n'a PAS ce niveau — provider `custom` generique
+   sans whitelist locale, donc deja debloque des que le niveau 3 l'est.
+
+`bifrost-proxy` (nginx/openresty, port 3086, colocalise avec Bifrost sur le
+VPS) a aussi un fichier `models.json` mais c'est purement un catalogue de
+decouverte pour `/v1/models` — ne bloque aucun appel reel.
+
+## Correctifs appliques
+
+Backups pris avant chaque modification (suffixe `.bak-20260911*`).
+
+1. **Bifrost core** (`/home/dsh-agent/bifrost/data/`) : `deepseek-v4.1-flash`
+   ajoute a `config.json` (cle provider opencode) et aux 21 lignes
+   `governance_virtual_key_provider_configs` (toutes les VK utilisant le
+   provider opencode) dans `config.db`. Container `bifrost` redemarre (healthy).
+   `bifrost-proxy/models.json` mis a jour pour la decouverte.
+
+2. **DSH** (`settings.yaml`) : `deepseek-v4.1-flash` ajoute aux catalogues
+   `opencode-direct` et `bifrost`. **Bonus** : `baseURL` du provider `bifrost`
+   corrige — pointait encore vers l'ancien relais NAS (100.86.197.88:3086) au
+   lieu du VPS local (100.94.90.119:3086), alors que DSH tourne sur le VPS et
+   n'a plus besoin de transiter par le NAS/Sfax depuis la relocalisation du
+   08/09 (voir bifrost-routing memory). Container redemarre, teste avec la
+   vraie cle BIFROST_API_KEY.
+
+3. **opencode natif VPS** (`/home/gemini-ops/opencode/config/opencode.json`) :
+   entree `deepseek-v4.1-flash` ajoutee au provider `bifrost`. Container
+   redemarre, entree confirmee dans la config active (`GET /config`).
+
+4. **openclaw-perso** (`openclaw.json`) : entree ajoutee a
+   `models.providers.bifrost.models` (avec metadata complete) et a
+   `agents.defaults.models` (cle prefixee `bifrost/`, comme les entrees
+   existantes — premiere tentative sans prefixe corrigee en cours de route).
+   Container redemarre, healthy, teste.
+
+5. **Hermes** (tt/nyora/perso/nabil) : aucune modification necessaire, deja
+   debloques via le niveau 3.
+
+## Verification
+
+Chaque instance testee en bout en bout via son propre chemin d'appel reel
+(pas juste `curl` depuis l'exterieur) : hermes-perso (NAS, relais bifrost-proxy
+NAS->VPS), DSH (VPS, vraie cle BIFROST_API_KEY), opencode natif VPS (cle
+opencode directe + header session), openclaw-perso (Authorization Bearer via
+bifrost-proxy). Toutes les reponses confirment `"model":"deepseek-v4.1-flash"`
+avec une reponse coherente.
+
+## Piege a retenir
+
+`bifrost-proxy` (nginx) n'accepte le VK que via `Authorization: Bearer <vk>`
+ou `x-api-key` — **pas** `x-bf-vk` en entree (ce header est ce qu'il injecte
+lui-meme vers Bifrost apres resolution). Un test manuel avec `x-bf-vk` direct
+contre `bifrost-proxy` echoue systematiquement (`virtual_key_required`), meme
+si la cle est valide — a ne pas confondre avec un vrai probleme de VK.
+
+## Reste ouvert
+
+Aucun. Les 5 assistants cites par Nabil (Hermes NAS x3, hermes-nabil VPS, DSH,
+openclaw-perso, opencode natif VPS) sont confirmes fonctionnels sur
+deepseek-v4.1-flash au 11/09/2026.