# 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.

## Addendum 11/09/2026 — token Gitea expiré + panne SSH memory-sync decouverte

En corrigeant le token Gitea `bolbol` expire (signale en fin de premiere session),
deux choses distinctes ont ete trouvees et traitees :

1. **Token sur le miroir reel** : le clone de travail avait ete corrige, mais
   pas le miroir bare que le cron `memory-sync.sh` utilise reellement
   (`/opt/memory-node/git/nas-runbooks.git` sur le VPS, proprietaire
   `claude-oversight`). Corrige et confirme via l'execution cron reelle de
   03:17 (`354361f..26bef7d main -> main`).

2. **Panne SSH decouverte au passage** : le meme script echouait depuis un
   moment sur 100% des runs (`Best0f@100.86.197.88: Permission denied
   (publickey,password)`) pour le volet rsync (nyora-notes + context-hub).
   Cause : consequence collaterale du verrouillage progressif de l'acces
   `Best0f` (migration vers comptes scopes claude-ops/gemini-ops/claude-code-ops,
   voir memoire `gemini-ops-access`) — ce script n'avait jamais ete migre.

   Fix : `memory-sync.sh` repointe sur `claude-ops@NAS`. Cle publique
   `claude-oversight@vps-memory-node` (deja utilisee, identity file existant)
   ajoutee a `authorized_keys` de `claude-ops` sur le NAS, avec **forced
   command** restreignant strictement a `rsync --server --sender` en lecture
   seule sur `/volume1/docker/nyora-notes/` et `/volume1/docker/context-hub/`
   uniquement (aucun shell, `no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding`).
   Backups : `authorized_keys.bak-20260911-ajout-cle-memory-node`,
   `memory-sync.sh.bak-20260911`.

   Verifie : `context-hub` synchronise integralement et a jour.

## Reste ouvert (nouveau, 11/09/2026)

`nyora-notes` bloque uniquement sur un sous-dossier isole,
`/volume1/docker/nyora-notes/app` (mode `700`, proprietaire uid 1026 —
seul dossier de toute l'arborescence hors de la convention `755` du reste).
Ni `claude-ops` (non proprietaire) ni le root conteneurise de `mcp-nas`
(`Operation not permitted` malgre `uid=0` — la couche de permission Synology
bloque meme le root du container) ne peuvent corriger ce mode.

**Action Nabil requise (une seule commande, en root ou via Best0f)** :
```
chmod -R g+rX /volume1/docker/nyora-notes/app
```
**RESOLU** -- applique par Nabil le 11/09/2026. Verifie en reel : run memory-sync
suivant (09:01) termine en rc=0, nyora-notes et context-hub integralement
synchronises, plus aucune erreur.