# nyora-notes-tt -- Pieces jointes : chantier dedie futur, EXHAUSTIF, architecture 2 phases (31/07/2026)

**Date** : 31/07/2026 (v3 -- ajoute l'architecture 2 phases proposee par Nabil)

## Decision finale (rappel v2)

Exhaustif : toutes les PJ, tous les dossiers. Dedoublonnage par CONTENU (similarite vectorielle sur texte extrait), jamais par nom de fichier -- une meme PJ peut etre diffusee plusieurs fois ou renommee. Chantier separe, lance APRES le backfill texte (205 dossiers, 2024-2026, deadline dimanche matin), jamais en parallele.

## Architecture 2 phases (idee de Nabil, 31/07/2026)

Decouple explicitement la partie LENTE-MECANIQUE (telechargement, contrainte OWA) de la partie LENTE-LLM (resume/embedding) -- les deux etaient bundlees dans le concept initial, ce qui les faisait payer le meme prix (45s d'attente OWA) meme pour la relecture. Separer permet a la phase 2 de tourner vite, sur fichiers locaux deja presents, sans plus jamais toucher OWA.

### Phase 1 -- Telechargement seul, aucun appel LLM

- Reproduit la structure des dossiers mail sur disque (miroir de l'arborescence O365).
- Chaque PJ telechargee et rangee dans le dossier correspondant, nommee `{N}_{note_id}_{nom_original_assaini}` -- le numero ET le note_id assurent la correspondance directe RAG<->Mail des cette etape (pas besoin d'attendre la phase 2 pour tracer quelle PJ vient de quel mail).
- **Piege a eviter (deja paye une fois avec folder_path)** : certains noms de dossiers mail contiennent un vrai `/` (ex "AO 66/2024 E Curatif"). Assainir ce caractere (remplacer par `-` ou equivalent) UNIQUEMENT pour le chemin disque -- la donnee en base garde le nom exact, seul le chemin fichier est assaini.
- Resultat : une archive locale complete et exploitable meme independamment du RAG.

### Phase 2 -- Resume + alimentation RAG, sur fichiers locaux

- Opere uniquement sur les fichiers deja telecharges en phase 1 -- plus aucune navigation OWA, donc rapide.
- Nouvelle table dediee `attachments` (PJ = entite de premiere classe, pas un champ JSON annexe sur `notes`) :
  - id, note_id (FK vers notes), original_filename, local_path, content_hash (dedup par contenu), extracted_text, summary, embedding_rowid (table vec dediee ou reutilisation de notes_vec avec discriminant de type).
- Objectif final explicite de Nabil : **hermes-tt consulte les PJ sans jamais avoir besoin de rouvrir O365** -- une fois phase 2 terminee, la dependance a la session OWA disparait completement pour la consultation (elle reste necessaire uniquement pour l'ingestion initiale).

## Cout (rappel v2, toujours valable)

Volet API : Mimo/DeepSeek couverts par le forfait Go OpenCode, embeddings Gemini sur cle Google separee (non chiffre). Volet temps : jusqu'a 45s par telechargement en phase 1, potentiellement plusieurs heures a plus d'une journee sur l'ensemble de l'arborescence -- mais ce cout ne concerne QUE la phase 1 desormais ; la phase 2 devrait etre nettement plus rapide une fois les fichiers locaux disponibles.

## Infrastructure deja disponible

- `GET /message/{index}/attachments` -- listing leger, deja integre au backfill texte en cours (colonne `notes.attachments`, JSON, best-effort) -- deviendra probablement redondant une fois la table `attachments` dediee en place, a evaluer.
- `GET /message/{index}/attachments/{filename}/text` -- combine actuellement telechargement+extraction en un seul appel ; pour l'architecture 2 phases, il faudra soit isoler la partie telechargement seule (nouvel endpoint ou parametre), soit telecharger via ce endpoint en phase 1 et ignorer le texte extrait a ce stade (extraction refaite en phase 2 depuis le fichier local si le format le justifie).