From 705ababfbe2a4b875c36978ca18583d839395c25 Mon Sep 17 00:00:00 2001 From: Claude Date: Sun, 2 Aug 2026 18:54:37 +0000 Subject: [PATCH] runbook: passation chantier PJ a hermes-tt (DeepSeek V4 Flash) + Mimo V2.5 --- .../passation-pj-hermes-tt-deepseek-mimo.md | 95 +++++++++++++++++++ 1 file changed, 95 insertions(+) create mode 100644 hermes-tt/passation-pj-hermes-tt-deepseek-mimo.md diff --git a/hermes-tt/passation-pj-hermes-tt-deepseek-mimo.md b/hermes-tt/passation-pj-hermes-tt-deepseek-mimo.md new file mode 100644 index 0000000..d409e82 --- /dev/null +++ b/hermes-tt/passation-pj-hermes-tt-deepseek-mimo.md @@ -0,0 +1,95 @@ +# Chantier PJ nyora-notes-tt : passation a hermes-tt (DeepSeek V4 Flash) + Mimo V2.5 + +**Instance auteur** : hermes-tt (a executer par) +**Date** : 2026-08-02 +**Tags** : nyora-notes-tt, pieces-jointes, passation, hermes-mail-browser +**Statut** : a demarrer + +--- + +## Decision (Nabil, 02/08/2026) + +Le script Python que Claude a ecrit (`download_attachments_phase1.py`, boucle mecanique +serree) fait planter hermes-mail-browser en quelques minutes des que l'activite est +intensive -- un processus de rendu Chromium se bloque a 100% CPU et ne se relache pas seul, +meme apres arret de la charge. Trois tentatives de correction (restart, watchdog ressources, +retry cible) n'ont pas resolu le probleme de fond, seulement contourne ses symptomes. + +Decision : confier le telechargement a **hermes-tt lui-meme**, en agissant via son propre +raisonnement (DeepSeek V4 Flash) plutot qu'une boucle Python rigide -- un agent LLM qui +reflechit entre chaque appel espace naturellement ses actions. Le classement/resume des PJ +une fois telechargees revient a **Mimo V2.5** (comprehension documentaire). + +--- + +## Etat exact au moment de la passation + +- 399 notes au total dans `nyora-notes-tt.db`, **~2 pieces jointes connues seulement** + (resultat du listing best-effort de l'ingestion initiale -- pas un chiffre garanti, + le scan exhaustif n'a jamais ete termine). +- Table `attachments` deja creee (id, note_id, folder_path, original_filename, local_path, + size_bytes, content_hash, extracted_text, summary, embedding_rowid, status, error_message, + downloaded_at, created_at) -- Phase 1 remplit jusqu'a `status`/`local_path`, Phase 2 + (Mimo) remplit `content_hash`/`extracted_text`/`summary`/`embedding_rowid`. +- Colonne `notes.attachments_scanned` (0/1) : resumabilite. 0 = pas encore verifie fraichement, + 1 = deja traite (que le resultat soit "aucune PJ" ou "PJ telechargee(s)"). +- Miroir de dossiers deja cree sous `/app/attachments` (hote : + `/volume1/docker/nyora-notes-tt/attachments/`) pour les 204 folder_path connus, `/` dans + un nom de segment assaini en `-` pour le chemin disque uniquement (la donnee en base garde + le nom exact). +- Script de reference `/app/download_attachments_phase1.py` deja present dans le conteneur + nyora-notes-tt (`/app/`) -- reutilisable comme base de logique (resolution message par + message_id, pas index brut ; nommage `{N}_{note_id}_{nom_assaini}`), mais **ne jamais + l'executer en boucle serree telle quelle** -- c'est exactement ce qui casse tout. + +--- + +## Points de vigilance CRITIQUES + +1. **Espacement obligatoire** : au moins 10-15s entre deux operations de niveau message + (`/search`, `/message/{index}/attachments`, telechargement). Le rythme naturel d'un agent + LLM (recherche -> reflexion -> action suivante) devrait suffire, mais ne pas enchainer + plusieurs appels dans une meme reponse sans y penser. +2. **Watchdog deja actif** : `/volume1/docker/nyora-notes-tt/watchdog_resources.sh` tourne en + fond sur le NAS (nohup, independant), surveille hermes-mail-browser toutes les 5 min, + redemarre proprement si CPU>80% ou RAM>1400Mo. Log : + `/volume1/docker/nyora-notes-tt/watchdog_hermes_mail.log`. **Ne pas le tuer** -- c'est un + filet de securite, pas un obstacle. +3. **Apres un restart hermes-mail-browser** (watchdog ou manuel) : le panneau de dossiers OWA + met du temps a se stabiliser. Une erreur 502 "Racine du compte introuvable dans le panneau + de dossiers" juste apres un restart = attendre encore 30-60s avant de retenter, pas un + echec definitif. +4. **Un seul moteur SQLite sur la DB live** : si acces direct a `nyora-notes-tt.db`, utiliser + `sqlean` (jamais `sqlite3` stdlib) + `PRAGMA busy_timeout=5000` a l'ouverture -- cf + `hermes-tt/nyora-notes-tt-backup-wal-moteur-mixte.md` (collision WAL deja vecue une fois). + +--- + +## Gap a verifier avant de commencer + +Le MCP de nyora-notes-tt (`search_mail_memory`, `get_entity_relations`, +`get_checkpoint_status`) est **lecture seule** -- aucun tool pour ecrire un statut de PJ ou +marquer une note scannee. Si hermes-tt dispose d'un acces shell/docker exec direct +(equivalent a mcp-nas cote Claude), il peut manipuler `nyora-notes-tt.db` directement en +respectant le point 4 ci-dessus. Sinon, ce gap MCP doit etre comble avant de pouvoir deleguer +proprement -- a signaler a Nabil si c'est le cas, ne pas bricoler une solution de contournement +fragile. + +--- + +## Phase 2 (Mimo V2.5) + +Une fois un fichier reellement present sous `/app/attachments/...` (chemin enregistre dans +`attachments.local_path`), extraire texte/resume via Mimo V2.5 et remplir +`content_hash` (dedup par CONTENU, jamais par nom de fichier -- decision Nabil du 31/07), +`extracted_text`, `summary`, `embedding_rowid`. Objectif final : hermes-tt consulte les PJ +sans jamais rouvrir O365. + +--- + +## References + +- `hermes-tt/nyora-notes-tt-roadmap-pieces-jointes.md` (31/07/2026) -- plan original 2 phases +- `hermes-tt/nyora-notes-tt-backup-wal-moteur-mixte.md` (02/08/2026) -- piege moteur SQLite mixte +- `hermes-tt/n8n-cron-orphelin-hermes-mail-browser-instabilite.md` (02/08/2026) -- 1er root cause instabilite (regle) +- Watchdog ressources : `/volume1/docker/nyora-notes-tt/watchdog_resources.sh` (02/08/2026, pas encore documente en runbook separe)