96 lines
5.1 KiB
Markdown
96 lines
5.1 KiB
Markdown
# 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)
|