1.9 KiB
issueRef, version, updatedBy, updatedAt
| issueRef | version | updatedBy | updatedAt | ||||
|---|---|---|---|---|---|---|---|
| #123 | 4 |
|
1785670261241 |
Contexte
Le besoin initial vient d’un futur plugin orienté développement Android, mais le périmètre validé pour ce chantier est strictement SDK générique. L’objectif n’est pas d’ajouter des API Android-first, mais de combler les trous du SDK public qui empêchent aujourd’hui tout plugin de développement un peu sérieux.
Ce qui existe déjà
- Manifest public
idea-plugin.json - Runtime
activate(ctx) commands,storage,loggerservices.workspace,services.tasks,services.terminal- Contributions
menus,menuItems,layouts,mcpServers
Problème
Le SDK public actuel est volontairement minimal. Il permet des plugins simples, mais pas un plugin d’outillage qui doit agir sur un workspace, lancer des outils externes, réagir aux événements du host, afficher une UI riche, ou analyser la structure d’un projet.
Décision de cadrage
Découper le besoin en tickets transverses, indépendants autant que possible.
Ordre de priorité retenu :
#124API fichiers/workspace#125API lancement de commandes et tâches#126API découverte/validation d’outillage externe#127API d’événements et de watch#128runtime UI/layout publique#129API d’analyse/requête de structure projet#130API de documents de configuration structurés
Garde-fous
- Pas d’API spécifique Android dans ce lot.
- Préserver une frontière SDK public vs runtime interne.
- Favoriser des primitives génériques réutilisables pour Android, iOS, Node, Python, Docker, etc.
- Éviter de forcer les plugins à dépendre de casts ad hoc ou d’objets runtime internes.
Définition de done du parapluie
Le parapluie est clôturable quand les tickets enfants retenus pour le MVP sont livrés ou explicitement re-scopeés avec arbitrage.