Blomios
ecad746c66
Rattrapage de l'état runtime .ideai/ (tickets #119-#139/#147 clôturés, compteur→149, ticket #148 clos et QA verte, métadonnées plugin android) — séparé du code de feature avant d'ouvrir le travail sur le nouveau bug de lancement CLI custom. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
33 lines
2.9 KiB
Markdown
33 lines
2.9 KiB
Markdown
---
|
||
id: "e33fd0ea-e7c6-40dc-a244-f158e44ac4a7"
|
||
number: 138
|
||
title: "SDK plugins: contrat de persistance plugin-owned hors projet et effacement total à la désinstallation"
|
||
status: "closed"
|
||
priority: "critical"
|
||
sprint: null
|
||
links: []
|
||
agentRefs: [{"agentId":"b4730d7f-c54d-4736-8a04-c6203aa2fd49","role":"assigned"}]
|
||
attachments: []
|
||
createdBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
|
||
updatedBy: {"kind":"user"}
|
||
createdAt: 1785702748769
|
||
updatedAt: 1785881187672
|
||
version: 5
|
||
---
|
||
Le lot #133/#135 traite déjà le confinement du package installé et l’absence d’écritures parasites au runtime, mais il reste un trou produit/API majeur : le SDK public et son exemple `sdk/IdeaSDK/examples/hello-plugin` montrent encore des écritures plugin sous `.ideai/hello-plugin.txt` et `.ideai/hello-plugin.json`, alors que l’objectif utilisateur est un modèle type VSCode où l’état propre au plugin ne pollue jamais le projet et disparaît entièrement à la désinstallation.
|
||
|
||
Objectif de ce ticket : trancher le contrat d’architecture/API, PAS l’implémenter.
|
||
|
||
À décider et documenter :
|
||
1. Séparer noir sur blanc les deux familles de données plugin :
|
||
- données métier du PROJET que le plugin modifie volontairement dans le workspace utilisateur (autorisées, explicites, relèvent de `workspace.*` / éventuellement `config` quand on touche un vrai fichier du projet) ;
|
||
- données PROPRES AU PLUGIN (prefs, cache, dernière sélection, index interne, état UI durable, config interne) qui doivent vivre hors project root, dans un store plugin-scopé sous app data, jamais sous `.ideai/` ni ailleurs dans le repo utilisateur.
|
||
2. Dire si `ctx.storage` clé/valeur suffit comme primitive canonique pour cet état plugin-owned, ou s’il faut une API publique supplémentaire de document structuré plugin-scopé (ex: JSON app-data du plugin) pour éviter de pousser les auteurs à détourner `ctx.services.config` vers `.ideai/*.json`.
|
||
3. Figer le contrat de désinstallation : la suppression du plugin doit aussi supprimer 100% de son état plugin-owned hors projet (storage, éventuels docs/config plugin-scopés, caches internes), sans toucher aux fichiers métier du projet que l’utilisateur a explicitement demandé au plugin de modifier.
|
||
4. Imposer l’alignement doc/exemples SDK : ne plus montrer `.ideai/...` comme emplacement par défaut pour l’état interne d’un plugin.
|
||
|
||
Critères d’acceptation :
|
||
- Une note d’architecture/API explicite distingue « project-owned » vs « plugin-owned ».
|
||
- La source de vérité et le cycle de vie du stockage plugin-owned sont écrits noir sur blanc (création, lecture, suppression à l’uninstall).
|
||
- Le ticket précise si une nouvelle API SDK est nécessaire ou si `ctx.storage` devient la voie canonique, et pourquoi.
|
||
- Le contrat est compatible avec l’exigence utilisateur : plugin désinstallé => plus aucun état propre au plugin, ni dans le projet, ni dans l’app data plugin. |