runbook: verification cle Kaggle API + piege notebook manuel invisible API

_INDEX.md

@@ -293,3 +293,4 @@
 - [common/deploiement-antigravity-cli-context-mode-ticket049-20260913.md](common/deploiement-antigravity-cli-context-mode-ticket049-20260913.md) -- Déploiement Antigravity CLI VPS (ticket infra-2026-09-049) : autorisation clé SSH opencode-ops sur NAS (gemini-ops:22222) validée agy-web/opencode, ajout et activation MCP baserow-nyora (fix 401 via insertion core_mcpendpoint workspace 186, test réel agy 10 tables OK), intégration pérenne context-mode sur agy-web (Dockerfile node:22-slim, npm install -g, plugin agy, doctor PASS) (13/09/2026)
 - [common/backup-usb-cache-io-errors-fix-20260914.md](common/backup-usb-cache-io-errors-fix-20260914.md) -- Échecs backup-usb.sh deux semaines de suite (07/09 puis 14/09/2026, rc=23) : diagnostic — rsync --link-dest relit le backup precedent (31/08) pour le hardlink, et des fichiers de .cache/uv (paquets Python hermes-tt) y remontaient des erreurs Input/output error ; la rotation ne purge qu'en succes donc les backups en echec s'accumulaient sans etre nettoyes. Script corrige (backup .bak-20260914 conserve) : exclusion des caches ephemeres (.cache/uv, .cache/pip, .cache/ms-playwright, __pycache__, node_modules/.cache) et fix du bug exit 0 implicite qui masquait l'echec au Task Scheduler DSM (status affichait Success malgre BACKUP EN ECHEC). Backup relance manuellement et valide : rc=0/rc=0, zero erreur I/O, 96G, _BACKUP_OK present (14/09/2026)
 - [common/watchdog-tailscale-bridge-faux-timeout-restart-20260916.md](common/watchdog-tailscale-bridge-faux-timeout-restart-20260916.md) -- tailscale-bridge-watchdog (cree 05/09, jamais documente/versionne avant ce jour) : fausse alerte Telegram "Echec apres redemarrage automatique / SOCKS5 Name does not resolve" causee par un timeout de 20s trop court sur le docker restart du pont (tailscaled+socat), sous charge NAS elevee (swap 5.0Gi/13Gi, load 8.08) ; pont en fait deja retabli par le 2e cycle de remediation automatique avant intervention. Fix : timeout 20s->45s + attente post-restart 15s->20s, rebuild/redeploy verifie. Piege decouvert au passage : docker compose up -d cible sur un seul service a recree le bridge (depends_on) sans le redemarrer (etat Created, corrige manuellement) -- toujours faire un up -d complet du compose en presence de depends_on. Repo tailscale-nyora-bridge initialise et pousse sur Gitea pour la premiere fois (16/09/2026)
+- [common/kaggle-ollama-tunnel-verification-20260917.md](common/kaggle-ollama-tunnel-verification-20260917.md) -- Vérification clé API Kaggle (format Bearer KGAT_, test santé via competitions/list?group=entered) et diagnostic du montage Kaggle GPU + Ollama + tunnel Cloudflare rapide pour LLM auto-hébergé (modèle Qwen3.6-27B-AEON-Ultimate-Uncensored). Piège majeur : un notebook exécuté à la main dans l'éditeur web est invisible à l'API (404 No runs found) -- seul un kernel poussé via kaggle kernels push est traçable/automatisable. Quota GPU (~30h/semaine), tunnel à URL aléatoire non stable, aucune auth réelle côté endpoint : montage jugé utilisable en rafale ponctuelle, pas comme provider Bifrost permanent. Note annexe : sudo passwordless de claude-ops sur fichiers 600 de Best0f (17/09/2026)

common/kaggle-ollama-tunnel-verification-20260917.md

@@ -0,0 +1,27 @@
+# Kaggle Ollama + tunnel Cloudflare — vérification clé et piège API
+
+**Date** : 17/09/2026
+**Contexte** : suite tuto YouTube "exécuter de grands modèles IA gratuitement via Kaggle" — notebook Kaggle GPU T4x2 + Ollama + tunnel Cloudflare rapide, pour exposer un LLM (choisi : Qwen3.6-27B-AEON-Ultimate-Uncensored-MTP, fine-tune communautaire non officiel base Qwen 3.6).
+
+## Clé Kaggle — localisation et vérification
+- Clé stockée dans `/volume1/docker/.claude/API_KEY.env` (propriétaire Best0f, permissions 600) sous `KAGGLE_API_KEY=KGAT_...`.
+- Format : token Bearer unique (nouveau système Kaggle, ne nécessite plus `KAGGLE_USERNAME` associé).
+- **Méthode de vérification fiable** : `GET https://www.kaggle.com/api/v1/competitions/list?group=entered` avec header `Authorization: Bearer <token>`. Retourne HTTP 200 (liste vide ou non) si le token est valide, HTTP 401 `{"code":401,"message":"Unauthenticated"}` si invalide. Utile comme test de santé générique de la clé.
+- Lister ses propres kernels : `GET /api/v1/kernels/list?group=profile` (le paramètre `mine=true` utilisé dans la doc/exemples historiques renvoie une erreur 400 "Invalid field" sur la version actuelle de l'API — piège documentaire, `group=profile` est le paramètre qui fonctionne).
+
+## Piège majeur découvert : notebooks lancés à la main = invisibles pour l'API
+Le kernel `nabilderouiche/notebook91770f3cc0`, exécuté interactivement depuis l'éditeur web Kaggle (Run manuel dans le navigateur, pas via `kaggle kernels push`), retourne `404 "No runs found for this kernel."` sur `GET /api/v1/kernels/status`. **L'API Kaggle ne trace un run consultable (status, logs, output) que pour les kernels déclenchés via l'API elle-même** (`kaggle kernels push` avec un `kernel-metadata.json`), pas pour un Run cliqué dans le navigateur.
+
+Conséquence directe : impossible d'automatiser la récupération de l'URL du tunnel Cloudflare (générée dans les logs du notebook à chaque run) sans d'abord faire basculer le fonctionnement du notebook cliqué-à-la-main vers un kernel versionné poussé/déclenché via l'API.
+
+## Limites structurelles (indépendantes de toute automatisation)
+- Quota GPU gratuit Kaggle : ~30h/semaine, exécution continue plafonnée (~9-12h par session).
+- Tunnel Cloudflare "rapide" (`cloudflared tunnel --url`) génère une URL aléatoire à chaque redémarrage — aucune stabilité d'adresse possible avec ce mode de tunnel.
+- Aucune authentification réelle côté endpoint exposé (le tuto utilise le placeholder `Ollama` comme "clé API").
+- Usage prolongé comme service d'inférence externe permanent sort du cadre d'usage prévu par Kaggle (notebooks interactifs, pas hébergement/proxy) — risque sur le compte vérifié par téléphone.
+
+**Conclusion** : ce montage reste utilisable en rafale ponctuelle (test lourd occasionnel), pas comme provider stable dans Bifrost au même titre que la convention -OC/-OR/-GQ/-NV déjà en place.
+
+## À noter au passage
+- `claude-ops` (compte NAS scopé, uid 1040) dispose d'un `sudo -n` (sans mot de passe) qui lui permet de lire des fichiers 600 appartenant à Best0f dans `/volume1/docker/.claude/` — contourne partiellement l'isolation prévue par la création des comptes scopés (voir historique gemini-ops/claude-code-ops). À signaler, pas corrigé ici.
+- Token Gitea `bolbol` fonctionnel en HTTPS via `gitea.bolbol.tn` (port 443 standard, **pas** le port 3232 qui timeout en accès direct — 3232 semble réservé au réseau interne docker/n8n).