feat: visibilité & recherche des partages dirigés #196

- icône share-2 bleue sur les fichiers partagés dans l'arborescence
- dossier virtuel Partage/ à la racine du home du destinataire (lecture seule /s/{token})
- recherche plein texte couvre les documents reçus (merge search_vaults, share_token)
- cache front invalidé à la création/révocation ; +2 tests non-fuite

docs/ROADMAP.md

@@ -1,6 +1,6 @@
 # ObsiGate — Roadmap
 
-> **Version :** 2.66.0 | **Dernière mise à jour :** 2026-10-10
+> **Version :** 2.67.0 | **Dernière mise à jour :** 2026-10-10
 > **Ce fichier ne contient que le travail à venir** (🔵 En cours + ⚪ Backlog) et un index compact
 > vers les fonctionnalités livrées.
 > - **Méthode de livraison à appliquer pour toute tâche : [DELIVERY_WORKFLOW.md](./DELIVERY_WORKFLOW.md)**
@@ -48,6 +48,15 @@
   - [x] Scope de `GET /api/shares` ; révocation créateur/admin uniquement
   - [x] UI : dialogue dirigé/public + destinataires, dashboard « partagé par X »
   - [x] i18n FR/EN, tests `test_directed_shares.py` (9), fiche feature
+  - [x] **Itération 2 (2026-10-11)** : icône « partagé » (share-2 bleu) sur les
+        fichiers porteurs d'un partage actif dans l'arborescence ; dossier
+        virtuel **Partage** à la racine du home du destinataire (fichiers reçus,
+        ouverture lecture seule `/s/{token}`) ; les documents reçus sont
+        **cherchables** (merge dans `search_vaults`, résultats
+        `home-<user>/Partage/…` avec `share_token`, clic → page de partage —
+        jamais l'éditeur du vault d'autrui) ; cache front invalidé à la
+        création/révocation. +2 tests (recherche trouvée par le destinataire,
+        aucune fuite vers un non-destinataire).
 
 ### 194. Dossier personnel par utilisateur (`<racine>/Home/<user>`)
 

docs/features/directed-shares-196.md

@@ -77,3 +77,31 @@ peut pas révoquer (403), créateur révoque, la révocation coupe l'accès.
   rechargement du dashboard (badge/rafraîchissement suffisent ; SSE existe
   si un vrai push est demandé).
 - La date d'« expiration » reste globale au partage (pas par destinataire).
+
+## Itération 2 — visibilité & recherche (2026-10-11)
+
+| Élément | Où |
+|---|---|
+| Icône « partagé » (share-2 bleu) sur les fichiers de l'arborescence | `frontend/js/sidebar.js` (`loadSharedPaths` + `sharedFileIconSync`, appliqué dans `loadDirectory` et `incrementalLoadDirectory`) |
+| Dossier virtuel **Partage** à la racine du home du destinataire | `frontend/js/sidebar.js` (injection `virtual-share` + rendu, clic fichier → `/s/{token}`) |
+| Recherche des documents reçus | `backend/services/search.py::_shared_results` (merge dans `search_vaults` avant pagination), `backend/routers/search.py` (passe `username`), `SearchResultItem.share_token` |
+| Clic sur un résultat reçu → page de partage | `frontend/js/search.js` |
+| Invalidation du cache front | `invalidateSharedPaths()` exporté, appelé par `openShareDialog` après création/révocation |
+
+Décisions :
+
+- **Dossier virtuel, pas physique** : l'indexeur exclut les symlinks
+  (sécurité path traversal) et un dossier réel ferait double indexation.
+  La source de vérité reste `data/shares.json`.
+- **Recherche à la volée** (`_shared_results`) : le contenu des documents
+  reçus est lu au moment de la requête, uniquement pour les destinataires —
+  jamais indexé dans le TF-IDF global, donc aucune fuite vers un
+  non-destinataire (testé). ponytail: lecture disque par requête, plafond
+  ~quelques centaines de partages reçus par user ; indexer dans le TF-IDF
+  avec un champ "destinataires" si le volume devient réel.
+- Icône déterminée côté client via `/api/shares` (déjà scopé #196) : la
+  liste des partages actifs "créés OU reçus" suffit — le créateur voit
+  l'icône sur son fichier source, le destinataire voit le dossier Partage.
+
++2 tests : `test_search_finds_received_share_for_recipient`,
+`test_search_does_not_leak_share_to_other_user`.