- host_health : ajoute CPU%, disque /%, température CPU, uptime ; pour gpu-01
un bloc GPU complet (température, utilisation, VRAM%, puissance via
rocm_scraper) en plus de llama-server. Requêtes concurrentes (asyncio.gather).
- cluster_status : ajoute le nb de nœuds k8s Ready et une ligne CrashLoopBackOff
(pods en boucle de crash) — complète le filtrage des pods terminés.
- metrics_block (contexte grafana) : ajoute le résumé GPU (util/temp/VRAM).
- Toutes les PromQL validées contre le Prometheus in-cluster.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Asa peut désormais AGIR sur le homelab quand on le demande explicitement, via
un outil de la boucle agentique — mais jamais sans confirmation.
- Outil admin_action(description) (contexte asa) : le LLM PROPOSE une action,
n'exécute rien. brain.ask_with_tools gagne `confirm_tools` : un tel outil
arrête la boucle et surface sa réponse (la question de confirmation).
- _handle_agentic : stocke la proposition en pending par session ; au tour
suivant « confirme » → agent.run_action → hermes-exec (hermes -z --yolo),
« annule » → oubli. Réutilise le handshake + jeton du contexte agent.
- admin_action n'est exposé que si _actions_available() (STT_ACTIONS_ENABLED
+ jeton) ; sinon retiré des schémas envoyés au modèle.
- Factorisation du ctx_debug du visualiseur. 1 test unitaire (confirm_tools
arrête la boucle). Serveur 0.9.0 ; doc stt.md + journal.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Asa ne répondait qu'à partir d'un contexte figé (RAG doc ou blocs live
pré-câblés, à présélectionner) → les questions à état live (« gpu-01 tourne
bien ? ») tombaient sur « la doc ne le précise pas ». Bascule vers une boucle
de function-calling : le modèle décide quels outils appeler puis répond à
partir de leurs résultats.
- Nouveau contexte `asa` (STT_DEFAULT_CONTEXT=asa, défaut prod) + tools.py
(registre schémas OpenAI + exécuteurs) + brain.ask_with_tools (boucle bornée
STT_TOOL_MAX_ITERS=4, réponse forcée au-delà ; _post factorisé + retry).
- Outils Phase 1, LECTURE SEULE : search_docs (RAG funk-docs), host_health
(gpu-01|storage-01 : up/charge/RAM + llama-server), cluster_status,
prometheus_query (PromQL arbitraire). Réutilisent sources.py / knowledge.py.
- Trace des outils renvoyée dans `context` → visualiseur HUD (un bloc par appel).
- 100 % local (Qwen3-8B) : tool-calling natif llama.cpp validé, survit au
/no_think. LiteLLM transmet bien les tools. PromQL validés contre le vrai
Prometheus in-cluster. 3 tests unitaires de la boucle (hors-ligne).
Web search (SearXNG in-cluster) = Phase 2 ; actions admin pilotées par le LLM
(hermes-exec comme outil) = Phase 3.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Sur un sujet absent de la doc Funk, le 8B comblait le vide en devinant
(« j'ai un switch ? » → tantôt « Oui » tantôt « Non », fausse assurance).
Le grounding marche (docs=6) mais la doc n'a rien à ancrer.
- config.py : system_prompt durci — si la doc ne mentionne PAS explicitement
l'élément, répondre « la doc Funk ne le précise pas », ne jamais affirmer
oui/non par déduction ni inventer de détail (modèle, marque, nombre, nom).
- admin/infra/reseau.md : section « Topologie physique — switch cluster »
(switch présent, modèle à confirmer) → comble le gap doc qui causait
l'hallucination sur le matériel réseau.
- bump 0.3.0 → 0.3.1
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Sans contexte, le modèle (qwen3-8b) hallucinait sur le homelab (« stockage
décentralisé », « worker nodes »…) car il ignore tout du cluster réel. Le
cerveau interroge désormais la collection funk-docs (la doc admin/ indexée) et
injecte les passages pertinents au prompt → il répond à partir de la vraie doc.
Coût ~nul : funk-docs et stt-memory partagent le même embedder nomic (:1238,
768 dim) → le vecteur de requête calculé pour le recall mémoire est réutilisé
pour la recherche doc (une embed, deux recherches). Dégrade en silence si
Qdrant/embed down (réponse sans doc plutôt qu'échec).
Module knowledge.py (STT_DOCS_RAG, TOPK=6, MIN_SCORE=0.45). Log /v1/ask
expose docs=<n>. Serveur 0.2.1 → 0.3.0.
Validé : « c'est quoi le nom des nœuds ? » → avant « worker/master nodes »
(inventé) ; après « Kubernetes ; nœuds storage-01, compute-01, compute-02 »
(tiré de la doc).
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Suite au déploiement 0.2.0, deux points observés en pilotant l'app en direct :
- Le log de timing (`ask … recall/gen/total`) n'émettait pas : uvicorn ne
configure que ses propres loggers → on attache un handler INFO sur `stt_server`.
- La chaîne LiteLLM→llama-server (ROCm gfx1031) se fige par à-coups (~1-2 min,
502 pour tous les appels, cf. incidents-llm-gpu.md). Résilience côté STT :
brain tente 2× (fermeture du client httpx entre les essais → connexion neuve si
le pool est vicié) et le timeout passe à 30s PAR tentative (≤ ~2× au pire).
Un blip transitoire devient une requête récupérée au lieu d'un 502.
bump serveur 0.2.0 → 0.2.1
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Cause de la latence 30-45s : l'endpoint d'embeddings (gpu-01:1238) peut se
geler ; recall ET remember l'attendaient ~20s chacun (timeout → dégradation
silencieuse), s'ajoutant à la réponse. Refactor :
- store (ex-remember) en BackgroundTasks → APRÈS la réponse, hors latence perçue ;
suppression de `?wait=true` (pas d'attente du flush Qdrant)
- recall renvoie aussi le vecteur de la requête → store le réutilise (1 embed/tour
au lieu de 2, le 2ᵉ portait sur le même texte)
- timeout recall serré (4s, STT_MEMORY_RECALL_TIMEOUT) : un embed lent/mort dégrade
vite (souvenirs vides) au lieu de bloquer ; store tolère 20s en arrière-plan
- clients httpx persistants (pooling/keep-alive) côté brain + longterm, fermés via
lifespan (plus de handshake TCP par appel)
- log de timing par requête (recall/gen/total/mem) pour diagnostiquer
- bump serveur 0.1.0 → 0.2.0
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
