blomios/IdeA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
ecad746c666d45816e4f176cbae2aabeb5afa3b5
IdeA/.ideai/tickets/123/carnet.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

1.9 KiB
Raw Blame History

issueRef, version, updatedBy, updatedAt
issueRef version updatedBy updatedAt
#123 5
kind
user
1785881187586

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.