feat: intégration TikTak #197-200 + scoped tokens, webhooks filtrés, listes mtime/size ; fix e2e-server BUG-112
This commit is contained in:
+58
-1
@@ -1,6 +1,6 @@
|
||||
# ObsiGate — Roadmap
|
||||
|
||||
> **Version :** 2.67.2 | **Dernière mise à jour :** 2026-10-10
|
||||
> **Version :** 2.68.0 | **Dernière mise à jour :** 2026-10-14
|
||||
> **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)**
|
||||
@@ -100,6 +100,63 @@
|
||||
|
||||
---
|
||||
|
||||
### 197. Listes de fichiers : `mtime` + `size` pour réconciliation externe (TikTak, Gitea #4)
|
||||
|
||||
- **Effort :** 0,5 jour | **Impact :** 🟡 | **Ouvert :** 2026-10-14 | **Statut :** ✅ livré le 2026-10-14
|
||||
- **Fiche :** [features/tiktak-integration-197-200.md](./features/tiktak-integration-197-200.md)
|
||||
- **Description :** un client de synchro doit détecter les fichiers modifiés en **un
|
||||
seul appel de liste**, sans relire chaque fichier. `GET /api/vault/{vault}/paths`
|
||||
n'exposait que `vault/path/name/type`.
|
||||
- **Sous-tâches :**
|
||||
- [x] `/paths` : `size`/`mtime`/`mtime_iso` par fichier (index, même contrat que
|
||||
`list_all_files`) ; `None` sur les répertoires
|
||||
- [x] `/browse` : `modified`/`modified_iso` ; outil MCP `list_directory` : `size`/`mtime`
|
||||
- [x] Cohérence read-after-write : `PUT …/save` rafraîchit l'index en synchrone
|
||||
- [x] Bug latent corrigé : `update_single_file`/`remove_single_file` exigeaient un
|
||||
absolu mais recevaient un relatif (no-op silencieux) — acceptent les deux
|
||||
- [x] Tests `tests/test_sync_lists.py` (7 : métadonnées + scénario de réconciliation)
|
||||
|
||||
### 198. Webhooks : `vault` dans la charge + filtre `vault` / `path_prefix` (TikTak, Gitea #3)
|
||||
|
||||
- **Effort :** 0,5-1 jour | **Impact :** 🟡 | **Ouvert :** 2026-10-14 | **Statut :** ✅ livré le 2026-10-14
|
||||
- **Fiche :** [features/tiktak-integration-197-200.md](./features/tiktak-integration-197-200.md)
|
||||
- **Description :** un consommateur externe (retours de synchro TikTak, phase 3) recevait
|
||||
tout, de tous les vaults, sans pouvoir filtrer.
|
||||
- **Sous-tâches :**
|
||||
- [x] Filtres optionnels `vault` (exact) + `path_prefix` (sous-arbre, `old/new_path`
|
||||
inclus) ; sans filtre = tout, comme avant ; `webhook_matches()` pur et testé
|
||||
- [x] `POST`/`PATCH`/`GET /api/webhooks` : filtres acceptés, modifiables (`""` = reset), exposés
|
||||
- [x] `PUT …/save` émet enfin `file_modified` (souscrit mais jamais dispatché)
|
||||
- [x] UI : champs filtre + badge, aide intégrée FR/EN mise à jour
|
||||
- [x] Tests `tests/test_webhook_filters.py` (10 : matching, persistance, dispatch simulé)
|
||||
|
||||
### 199. Clés API à portée limitée — vault unique + fichiers seuls (TikTak, Gitea #2)
|
||||
|
||||
- **Effort :** 1-2 jours | **Impact :** 🟡 | **Ouvert :** 2026-10-14 | **Statut :** ✅ livré le 2026-10-14
|
||||
- **Fiche :** [features/tiktak-integration-197-200.md](./features/tiktak-integration-197-200.md)
|
||||
- **Description :** la clé que TikTak conservera ne doit toucher que le vault « TikTak »
|
||||
et que les fichiers — en cas de fuite, le reste de la mémoire reste hors de portée.
|
||||
- **Sous-tâches :**
|
||||
- [x] `POST /api/auth/tokens` : `vaults?` (sous-ensemble du créateur, 400/403 sinon) +
|
||||
`scope` (`full` défaut | `files`) ; JWT + record portent la portée
|
||||
- [x] Vault : `check_vault_access`/`require_vault_access` existants → 403 hors vault (REST + MCP)
|
||||
- [x] Périmètre `files` : `TokenScopeMiddleware` (403 REST, stateless) + `call_tool`/
|
||||
`propose_*`/`list_tools`/`vault://` (`token_scope_denied`, `FILES_SCOPE_TOOLS`)
|
||||
- [x] UI : sélecteur de portée + champ vaults, badge et vaults listés (i18n FR/EN)
|
||||
- [x] Compatibilité : clés existantes = `full`, inchangées
|
||||
- [x] Tests `tests/test_scoped_tokens.py` (13) + guides API_REST (§2.3, §5) / MCP
|
||||
|
||||
### 200. Provisionnement du vault dédié « TikTak » (exploitation, Gitea #1)
|
||||
|
||||
- **Effort :** 0,5 jour | **Impact :** 🟡 | **Ouvert :** 2026-10-14 | **Statut :** ✅ livré le 2026-10-14 (runbook)
|
||||
- **Fiche :** [features/tiktak-integration-197-200.md](./features/tiktak-integration-197-200.md) (§#200)
|
||||
- **Description :** opération unique côté hébergement, aucun code requis : dossier hôte +
|
||||
montage conteneur + `POST /api/vaults/add` (persisté, sans redémarrage) + ACL du
|
||||
compte de synchro + clé limitée (#199) + webhook filtré (#198) + recette `curl`
|
||||
d'acceptation. **Reste à exécuter sur l'hôte** (suivre le runbook, puis fermer Gitea #1).
|
||||
|
||||
---
|
||||
|
||||
### 77. Application Desktop native — Tauri (Windows / Linux / macOS)
|
||||
|
||||
- **Effort :** 8-12 jours | **Impact :** 🟡 | **Framework :** Tauri v2 (Rust + Webview)
|
||||
|
||||
Reference in New Issue
Block a user