bruno
ce23ab38f7
- ROADMAP: ne garde que le travail a venir + index compact du complete (995 -> ~155 lignes); detail deplace vers docs/features/ et docs/archive/ - docs/features/: fiches detaillees #74, #75, #76, #77, #78, #79 - docs/archive/COMPLETED_v1-v2.md: detail des items courts livres - CHANGELOG: alignement sur les tags (2.0.0 date, 2.2.0/2.2.1 ajoutes, Unreleased = travail #79 post-2.2.1) - AGENTS.md + docs/DELIVERY_WORKFLOW.md: methode de livraison unique (Definition of Done) referencee par ROADMAP, CONTRIBUTING, ISSUES_TODOLIST
15 KiB
15 KiB
ObsiGate — Roadmap
Version : 2.2.1 | Dernière mise à jour : 2026-09-11 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
- Historique des versions : CHANGELOG.md
- Détail des fonctionnalités livrées : docs/archive/COMPLETED_v1-v2.md
- Fiches détaillées par feature : docs/features/
- Bugs / TODO : ISSUES_TODOLIST.md
Légende
| Icône | Signification |
|---|---|
| ✅ | Terminé |
| 🔵 | En cours |
| ⚪ | Prévu / Backlog |
| 🔴 Impact | Critique / Bloquant |
| 🟡 Impact | Utile / Attendu |
| 🟢 Impact | Nice-to-have / Confort |
Convention : chaque item porte un ID stable
#NN(clé de jointure entre roadmap, changelog et commits). Une fonctionnalité livrée sort de ce fichier et entre dans l'index « Complété » ci-dessous, avec son détail dansdocs/features/ou l'archive.
🔵 En cours
77. Application Desktop native — Tauri (Windows / Linux / macOS)
- Effort : 8-12 jours | Impact : 🟡 | Framework : Tauri v2 (Rust + Webview)
- Statut : livré (A→F) — projet Tauri, backend Python embarqué, fonctionnalités natives, build CI, UX, 16 tests Rust. Détail complet : features/desktop-tauri.md
- Reste à faire :
- Signature de code Windows (optionnel mais recommandé)
- Wizard « Choisissez votre vault » au 1er lancement (optionnel)
- Jumplist vaults récents dans le menu Démarrer (optionnel)
- 6 tests E2E manuels : installation, tray icon, notifications natives, association
.md, auto-update, désinstallation
79. Assistant IA — Outils (function calling) & serveur MCP
- Effort : 10-15 jours | Impact : 🟡
- Statut : 🔵 Phase 0 + B1/B2/B3/B7 + G livrés (2026-09-11). Détail complet : features/ai-tools-mcp.md
- Description : Transformer l'assistant BooksLM en agent (lire, chercher, lister, ouvrir, modifier) via function calling natif, puis exposer ObsiGate à des clients MCP externes (Claude Desktop, Cursor…). Les deux fronts consomment une couche d'outils partagée.
- Reste à faire :
- A2. Extraire la logique métier des routes
backend/main.pyen services réutilisables (partiel) - B4. SSE réellement streaming ; B5. confirmations UI (carte Apply, diff) ; B6. outils navigation
open_file/reveal_in_tree - C. Catalogue lecture & recherche (vaults, read, backlinks, backups, search, tags)
- D. Catalogue mutations (create/edit/append/rename/move/delete) + confirmations two-step
- E. Serveur MCP (Streamable HTTP
/mcp, auth Bearer JWT,propose/apply, toggle par vault) - F. Durcissement (rate limiting, redaction secrets, OpenAPI + guide MCP, E2E)
- A2. Extraire la logique métier des routes
- Documentation : AI_ARCHITECTURE_GUIDE.md (architecture, catalogue d'outils, sécurité, phases).
⚪ Backlog — Priorité 3 (P3)
62. Collaboration temps réel — Édition simultanée
- Effort : 5-7 jours | Impact : 🟢
- Description : Permettre à plusieurs utilisateurs d'éditer le même document markdown en même temps, comme Google Docs. Chaque personne voit en temps réel ce que les autres tapent, avec leur curseur affiché en couleur.
- WebSocket : connexion persistante bidirectionnelle entre le navigateur et le serveur. Contrairement à HTTP où le client doit constamment demander « y a-t-il du nouveau ? » (polling), le WebSocket permet au serveur de pousser les changements instantanément. Une room WebSocket est créée par fichier ouvert — tous les utilisateurs qui éditent le même fichier rejoignent la même room.
- Yjs + CRDT : Yjs est une bibliothèque qui implémente un algorithme CRDT (Conflict-free Replicated Data Type). Imagine deux personnes qui tapent en même temps au même endroit — sans CRDT, on aurait un conflit et du texte perdu. Avec CRDT, les deux modifications sont fusionnées mathématiquement sans perte. Chaque caractère reçoit un identifiant unique, et l'ordre final est déterministe même si les opérations arrivent dans le désordre. Pas besoin de verrouiller le fichier ni de résoudre des conflits manuellement.
- Awareness : chaque utilisateur voit le curseur des autres (position, sélection) représenté par un nom et une couleur. Un indicateur dans la barre d'outils montre qui est connecté.
- Persistance : le serveur sauvegarde périodiquement le document (debounce 2s après la dernière modification) pour que les changements survivent à une déconnexion.
- Pourquoi c'est important : Permet le travail d'équipe sur la documentation, les notes de réunion, les spécifications techniques, les brainstorms. C'est le passage d'ObsiGate de « outil personnel » à « outil d'équipe ».
- Sous-tâches :
- Serveur WebSocket : endpoint
/ws/collab/{vault}/{path}avec gestion des rooms - Intégration Yjs :
Y.Docpartagé,Y.Textpour le contenu markdown - Awareness : curseurs colorés par utilisateur, sélections visibles
- Synchro backend : persistance périodique du document (debounce 2s)
- Gestion des droits : vérification
check_vault_accesspar connexion WS - UI : indicateur de présence (avatars dans la barre d'outils éditeur)
- UI : curseurs distants dans CodeMirror (extension collaborative)
- Gestion des déconnexions : reconnexion automatique, merge state au retour
- Tests de charge : 5+ utilisateurs simultanés sur le même fichier
- Serveur WebSocket : endpoint
⚪ Backlog — Priorité 4 (P4)
69. Éditeur mobile natif — Interface tactile optimisée
- Effort : 2-3 jours | Impact : 🟢
- Description : Refonte de l'expérience mobile pour l'édition : barre d'outils contextuelle, presse-papiers optimisé, gestes tactiles (swipe pour actions rapides), mode lecture plein écran.
- Sous-tâches :
- Barre d'outils mobile flottante : bold, italic,
code, liste, lien (inspirée de l'éditeur Obsidian mobile) - Raccourcis swipe : gauche → backlinks, droite → table des matières
- Mode lecture : cache sidebar + header, plein écran, swipe horizontal pour page suivante
- Presse-papiers : bouton « Coller » persistant (iOS contourne restriction clipboard)
- Adaptation CodeMirror : hauteur ajustable, police agrandissable (pinch zoom)
- Barre d'outils mobile flottante : bold, italic,
70. Recherche sémantique — Embeddings vectoriels
- Effort : 4-5 jours | Impact : 🟢
- Description : La recherche actuelle (TF-IDF) ne trouve que les documents contenant EXACTEMENT les mots tapés. La recherche sémantique comprend le SENS de la requête et trouve des documents pertinents même s'ils utilisent des mots différents.
- Exemple concret : Vous cherchez « comment sauvegarder mes données ». La recherche TF-IDF ne trouvera que les documents contenant « sauvegarder » ET « données ». La recherche sémantique trouvera aussi un document titré « Stratégie de backup automatique » ou « Protection contre la perte de fichiers » parce qu'elle comprend que ces phrases parlent de la même chose.
- Fonctionnement technique :
- Chaque document (ou chunk de ~512 tokens) est converti en un vecteur (une liste de 384 nombres) par un modèle de langage léger comme
all-MiniLM-L6-v2(80 Mo, s'exécute en ~2ms par document sur CPU). Ce vecteur capture le sens — deux phrases qui veulent dire la même chose auront des vecteurs très proches. - Au moment de la recherche, la requête utilisateur est elle aussi convertie en vecteur.
- On calcule la similarité cosinus entre le vecteur de la requête et les vecteurs de tous les documents. Les documents avec la similarité la plus élevée sont retournés.
- Recherche hybride : on combine le score TF-IDF (pertinence par mots-clés exacts) et le score sémantique (pertinence par sens) via RRF (Reciprocal Rank Fusion) — les documents bien classés par les deux méthodes remontent en premier.
- Chaque document (ou chunk de ~512 tokens) est converti en un vecteur (une liste de 384 nombres) par un modèle de langage léger comme
- Stockage : les vecteurs sont stockés avec FAISS (Facebook AI Similarity Search), une bibliothèque optimisée qui permet de chercher parmi des millions de vecteurs en quelques millisecondes.
- Indexation : les embeddings sont générés une fois à l'indexation du fichier (pas à chaque recherche). Un fichier modifié voit son embedding regénéré automatiquement par le watcher.
- Pourquoi c'est important : La recherche par mots-clés échoue dans ~30% des cas où l'utilisateur ne se souvient pas des mots exacts utilisés dans ses notes. La recherche sémantique résout ce problème. C'est particulièrement utile pour les gros vaults (500+ notes) où on ne peut pas tout parcourir manuellement.
- Sous-tâches :
- Génération d'embeddings : modèle
all-MiniLM-L6-v2viasentence-transformers(Python) ou appel API externe - Stockage : index vectoriel avec
numpy+faiss(ouusearchpour performance) - Indexation : embedding par chunk de 512 tokens avec recouvrement
- Recherche hybride : combinaison TF-IDF + similarité cosinus (RRF — Reciprocal Rank Fusion)
- UI : toggle « Recherche sémantique » dans la barre de recherche
- UI : score de similarité dans les résultats
- Génération d'embeddings : modèle
73. Synchronisation multi-appareils — Obsidian Sync compatible
- Effort : 6-8 jours | Impact : 🟢
- Description : Synchronisation des vaults entre plusieurs instances d'ObsiGate via un protocole de synchronisation décentralisé ou compatible Obsidian Sync. Alternative self-hosted à Obsidian Sync.
- Sous-tâches :
- Protocole : évaluation CRDT vs OT vs diff/patch pour fichiers markdown
- Transport : WebSocket ou polling HTTPS avec compression
- Merge strategy : LWW (Last Writer Wins) avec historique des deux versions
- Détection de changements : hash SHA-256 par fichier, journal des modifications
- UI : page « Synchronisation » avec statut par appareil, historique des syncs
- Conflits : UI de résolution manuelle (diff côte à côte entre version locale et distante)
- Chiffrement : optionnel, chiffrement AES-256-GCM avant transmission
- Pairing : échange de clé publique + code QR pour appairage des appareils
✅ Complété — index
Détail complet dans docs/archive/COMPLETED_v1-v2.md et docs/features/. Cette table est la seule source de navigation ; ne pas re-détailler les items livrés ici.
| # | Domaine / fonctionnalité | Version | Détails |
|---|---|---|---|
| 1–8 | Fondations (FastAPI, TF-IDF + stemming, watchdog, SPA, sécurité, path traversal, gzip, PWA) | 1.0.0→1.4.0 | archive |
| 9–20 | UX & productivité (share, webhooks, dashboard, conflits, backlinks, redaction, backups, graphe, header, aperçu) | 1.5.0→1.6.0 | archive |
| 21–22 | Architecture (split app.js → 16 modules, validateur imports CI) |
1.5.1 | archive |
| 23–25 | CI/CD & qualité (Gitea Actions, Ruff/Mypy/Bandit/Pip-audit, pytest) | 1.6.0 | archive |
| 26–29 | AI Editor (toolbar, multi-provider, 16 endpoints, auto-save) | 1.7.0 | archive |
| 30–39 | Fonctionnalités avancées (export PDF, palette, mobile, drag & drop, filtres, indexation non-bloquante) | 1.8.0→1.9.0 | archive |
| 40–46 | Gestion des backups (diff, gestionnaire, purge, auto, rétention) | 1.9.0 | archive |
| 47–57 | Mermaid.js (22 templates, live preview, thèmes, zoom, plein écran, pré-processeur Obsidian) | 2.0.0 | archive |
| 58 | Tests E2E Playwright (44 desktop + 12 mobile, CI) | 2.0.0 | archive |
| 59 | Mode hors-ligne PWA complet (IndexedDB, file de synchro, conflits) | 2.0.0 | archive |
| 63 | Internationalisation i18n FR/EN | 2.0.0 | archive |
| 65 | Thèmes personnalisés (light/dark/high-contrast/sepia, import/export) | 2.0.0 | archive |
| 66 | Export multi-formats (HTML, MD bundle, ePub) | 2.0.0 | archive |
| 71 | Tableau de bord administrateur | 2.0.0 | archive |
| 64 | MFA (TOTP + WebAuthn + recovery codes) | 2.1.0 | archive |
| 74 | Support complet des documents PDF | 2.1.0 | features/pdf.md |
| 75 | Éditeur multi-panneaux (Split View) | 2.1.0 | features/split-view.md |
| 61 | Plugins système (sandbox Web Worker, hooks, 9 endpoints) | 2.2.0 | archive |
| 67 | Notifications web — Push API | 2.2.0 | archive |
| 68 | Health check enrichi | 2.2.0 | archive |
| 72 | API publique documentée — OpenAPI 3.1 | 2.2.0 | archive |
| 76 | BooksLM — Console AI contextuelle par répertoire | 2.2.0 | features/bookslm.md |
| 78 | Éditeur Excalidraw | 2.2.0 | features/excalidraw.md |
| 77 | Application Desktop native — Tauri | 🔵 en cours | features/desktop-tauri.md |
📊 Résumé des efforts
| Priorité | Items | Effort total estimé |
|---|---|---|
| ✅ Complété | #1 → #59, #61, #63–68, #71, #72, #74–76, #78 | ~82 jours réalisés |
| 🔵 P2 restant | #77 Desktop : signature code (optionnel), wizard 1er lancement (optionnel), 6 tests E2E manuels | ~1-2 jours |
| ⚪ P3 restant | #62 Collaboration Yjs (5-7j) · #79 Assistant IA outils + MCP (10-15j, Phase 0 + G livrés) | ~15-22 jours |
| ⚪ P4 restant | #69 Mobile éditeur (2-3j) · #70 Sémantique (4-5j) · #73 Sync (6-8j) | 11-16 jours |
| Total restant | 6 items + finitions | ~27-39 jours |
Notes
- Les items P3/P4 ne sont pas ordonnés par priorité interne — à raffiner selon les retours utilisateurs.
- L'effort inclut le développement + tests unitaires + intégration CI, mais pas la documentation utilisateur.
- Les items marqués 🟢 (nice-to-have) sont de bons candidats pour des contributions externes.
- Maintenance de ce fichier : quand un item passe à ✅, déplacer son détail vers
docs/features/<slug>.md(grosse feature) oudocs/archive/COMPLETED_v1-v2.md(item court), ajouter une ligne dans l'index « Complété », et consigner la version dans le CHANGELOG.