runbook: passation chantier PJ a hermes-tt (DeepSeek V4 Flash) + Mimo V2.5
This commit is contained in:
Claude
@@ -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)
|
||||
Reference in New Issue
Block a user