---
issueRef: "#123"
version: 4
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
updatedAt: 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`, `logger`
- `services.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 :
1. `#124` API fichiers/workspace
2. `#125` API lancement de commandes et tâches
3. `#126` API découverte/validation d’outillage externe
4. `#127` API d’événements et de watch
5. `#128` runtime UI/layout publique
6. `#129` API d’analyse/requête de structure projet
7. `#130` API 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.