bolbol/nas-runbooks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs(protocol-infra): interdiction Nabil-Key et obligation cles virtuelles dediees

Browse Source
This commit is contained in:
Gemini
2026-09-04 21:53:19 +01:00
parent da376a630e
commit 957e9a8090
1 changed files with 25 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
common/PROTOCOL-INFRA.md
+25
View File
@@ -431,3 +431,28 @@ Le MCP natif de Baserow (image officielle, non patchable) ne couvre que les lign
## FIX -- baserow-schema-mcp : flux SSE bloque via le reverse-proxy DSM, resolu en HTTP 1.0 backend (2026-08-17, resolu)
Une fois la regle DSM `baserow-schema.bolbol.tn` -> 3101 creee (cert Let's Encrypt auto-provisionne OK, TLS OK), le endpoint `/mcp/<token>/sse` restait silencieusement bloque (0 octet recu avant timeout), reproduit avec plusieurs clients. **Resolu par Nabil : choisir HTTP 1.0 (pas 1.1) comme version backend dans le formulaire DSM du reverse-proxy.** Reteste apres coup avec succes sur curl (ALPN h2 par defaut) ET httpx pur HTTP/1.1 -- pas de regression cote client malgre le libelle "HTTP 1.0" trompeur (mode de proxying DSM->backend moins strict sur le chunked/keep-alive, pas une vraie retrogradation cote client). A appliquer directement sur toute future regle DSM devant un service SSE/MCP si le meme blocage silencieux apparait. Detail : common/baserow-schema-mcp.md.
## RÈGLE -- Interdiction absolue d'utiliser Nabil-Key (bfk-0cd1fb...) dans les agents Hermes et services NAS, clés virtuelles dédiées obligatoires (2026-09-04)
1. **Périmètre et cause racine** :
- La clé `Nabil-Key` (`bfk-0cd1fba7d440ca2eefd30b28a7349b7d28422dcbc49e982d`) est STRICTEMENT réservée à l'usage personnel direct de Nabil et dispose d'un forfait plafonné à 8 $/mois (sur OpenCode Go).
- Toute utilisation de cette clé par un agent automatique ou un conteneur draine le quota personnel de Nabil et bloque l'inférence.
- **INTERDICTION ABSOLUE** de configurer ou d'injecter cette clé dans les conteneurs Hermes (`model.api_key`, `auxiliary.*.api_key`), les services NAS, les scripts de veille ou les cron jobs.
2. **Clés virtuelles dédiées par instance** :
Chaque instance Hermes et chaque consommateur doit impérativement utiliser sa propre clé virtuelle isolée :
- `hermes-agent-perso` : `vk-hermes-perso` (`sk-bf-bb062ad2-438d-4176-9f85-b703168b6df0`)
- `hermes-agent-nyora` : `vk-hermes-nyora` (`sk-bf-7b194df6-9169-42b7-87cf-4545585b4d7c`)
- `hermes-agent-tt` : variable d'environnement `OPENCODE_GO_API_KEY` (avec `api_key: ''` dans `config.yaml`)
- `context-hub` : sa propre clé dédiée (`bfk-e5832b...`)
- `nyora-convert-api` : `vk-nyora-notes-tt` (`sk-bf-2685...`)
3. **Piège de patch partiel (Ticket infra-2026-09-014)** :
- Lors d'une migration ou d'un changement de clé dans Hermes, veiller à auditer **TOUS** les blocs de configuration : `model.api_key` ET les sous-blocs `auxiliary.vision.api_key`, `auxiliary.embeddings.api_key`, etc.
- Un remplacement restreint à `model.api_key` laisse la vision ou les tâches annexes débiter l'ancienne clé silencieusement.
4. **Routage Bifrost VPS via bifrost-proxy** :
- Les requêtes OpenCode Go doivent transiter par `bifrost-proxy:3086`, qui assure l'injection du header requis `x-bf-eh-x-opencode-session` vers Bifrost VPS (`bifrost.vps.bolbol.tn:8080`).
Détail complet : `common/piege-virtual-key-nabil-key-bifrost-hermes-20260904.md`.