---
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: "qa"
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":"agent","agent_id":"b4730d7f-c54d-4736-8a04-c6203aa2fd49"}
createdAt: 1785702748769
updatedAt: 1785703680849
version: 4
---
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.