blomios/IdeA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a3d94d4d5e532e25353a204906121b42ab04abc6
IdeA/.ideai/tickets/138/issue.md
Blomios ecad746c66 chore(tickets): synchronise les statuts tickets et l'état plugin android 
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>
2026-08-05 13:40:44 +02:00

2.9 KiB
Raw Blame History

id, number, title, status, priority, sprint, links, agentRefs, attachments, createdBy, updatedBy, createdAt, updatedAt, version
id number title status priority sprint links agentRefs attachments createdBy updatedBy createdAt updatedAt version
e33fd0ea-e7c6-40dc-a244-f158e44ac4a7 138 SDK plugins: contrat de persistance plugin-owned hors projet et effacement total à la désinstallation closed critical null
agentId role
b4730d7f-c54d-4736-8a04-c6203aa2fd49 assigned
kind agent_id
agent a6c6ea12-bfc6-4bdc-8031-324102dfa34d
kind
user
1785702748769 1785881187672 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.