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

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.
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.
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.
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)

5.1 KiB Raw Blame History