runbook: guardrails flotte hermes (hard_stop, tirith, verificateur croise) + incidents decouverts
This commit is contained in:
@@ -200,3 +200,5 @@
|
||||
- [hermes-tt/nyora-notes-tt-phase2-embedding-relance-post-sweep-08-08-2026.md](hermes-tt/nyora-notes-tt-phase2-embedding-relance-post-sweep-08-08-2026.md) -- Sweep Phase1 toutes annees termine seul via son plafond MAX_BATCHES=15 (3 notes restantes, cas OWA permanents deja connus, aucune intervention necessaire). Phase 2 + embedding relances sur le volume complet via nouveau script run_phase2_embed_full.sh (boucle jusqu'a epuisement + embedding + audit) : 24/27 PJ telechargees extraites avec succes, 24/24 embeddees (100%), content_hash 27/27 (100% des telechargees), ao_reference 23/27. JOIN exact content_hash avec onedrive_documents : 3 correspondances (1 seul le 08/08 matin, confirme la resorption progressive). Piege : docker exec -i obligatoire pour un heredoc Python en stdin ; sqlite_vec.load(conn) obligatoire avant toute requete sur *_vec, y compris en audit ponctuel (08/08/2026)
|
||||
- [hermes-tt/download-attachments-phase1-bug-timeout.md](hermes-tt/download-attachments-phase1-bug-timeout.md) -- Sweep PJ 2026 degradait la session OWA jusqu'a marquer des notes attachments_scanned=1 sans verification reelle : deux endpoints (search_folder par dossier, list_attachments par note) catchaient un timeout exactement comme un 404 et le mettaient en cache comme vide. Fix : contrat None (inconnu, a retenter) vs liste vide (verifie vide/404) strict + une retentative + circuit-breaker 3 echecs consecutifs. Filtre year_bucket ajoute (absent avant, bug distinct meme session), parametrable ATTACH_YEAR_BUCKET pour reprendre sur 2024/2025 apres 2026. Teste 2x5 notes (07/08/2026)
|
||||
- [hermes-tt/nyora-notes-tt-message-id-elem-id-volatile-08-08-2026.md](hermes-tt/nyora-notes-tt-message-id-elem-id-volatile-08-08-2026.md) -- Piste "message_id natif via elem_id OWA" FERMEE : elem_id (attribut id de ligne) s'est revele VOLATILE (GUID de rendu regenere a chaque appel -- test rigoureux 0/19 messages stables, ensembles disjoints, meme index -> id different). Un premier test a 1 seul message en position 0 sur appels rapproches l'avait faussement valide (DOM re-utilise). Decision : message_id reste le hash SHA256(subject|date|sender) STABLE ; conversation_id (data-convid, niveau THREAD, regex ciblee jamais split sur |) et fix retry /search count:0 transitoire CONSERVES. Garde-fou dedup verifie (message_id = cle de dedup ; 399 notes toutes en dossiers 'done' jamais re-scannes ; 0 note degradee inseree pendant la fenetre elem_id). Lecon SPA : tester un id DOM sur >=2 rendus reels et plusieurs messages (08/08/2026)
|
||||
|
||||
- [common/guardrails-flotte-hermes-hard-stop-tirith-verificateur-12-08-2026.md](common/guardrails-flotte-hermes-hard-stop-tirith-verificateur-12-08-2026.md) -- hard_stop_enabled et tirith_enabled actives sur les 4 instances (etaient false), verificateur delegate_task croise (NAS genere DeepSeek/verifie Mimo V2.5, hermes-nabil inverse) ; faille provenance mail->RAG confirmee par lecture code mais pas corrigee (chantier a part) ; hermes-agent-tt trouve down 8h (mort non-propre, cause inconnue), hermes-workspace-perso bloque par port 3030 orphelin (12/08/2026)
|
||||
|
||||
Reference in New Issue
Block a user