blomios/IdeA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a3d94d4d5e532e25353a204906121b42ab04abc6
IdeA/.ideai/tickets/126/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.7 KiB
Raw Blame History

issueRef, version, updatedBy, updatedAt
issueRef version updatedBy updatedAt
#126 8
kind
user
1785881187599

Problème

Un plugin de dev a souvent besoin de savoir si un outillage externe existe, où il se trouve, quelle version est installée, et si l’environnement est valide. Le SDK public n’expose pas aujourd’hui cette capacité comme primitive générique.

Pourquoi c’est global

Ce besoin vaut pour Android SDK, Java, Node, Python, Docker, Go, Rust toolchain, etc. Le ticket doit fournir une abstraction générique de découverte/validation d’outillage, pas une API dédiée Android.

Ce que ce ticket doit produire

Une API publique permettant idéalement :

  • résolution d’un exécutable ou d’une toolchain par nom/id
  • lecture de version
  • inspection de variables d’environnement pertinentes
  • validation de prérequis déclaratifs
  • restitution d’un diagnostic structuré exploitable par une UI plugin

Contraintes d’architecture

  • La source de vérité peut s’appuyer sur fichiers, env et exécution d’outils, mais l’API exposée doit rester stable et agnostique.
  • Ne pas figer de modèle métier Android.

Dépendances

  • Dépend de #124 pour l’accès workspace/config.
  • Dépend de #125 pour l’exécution contrôlée des commandes de détection.

Non-objectifs

  • Pas de gestion d’émulateur/device manager.
  • Pas d’installation automatique d’une toolchain dans ce ticket.

Critères d’acceptation

  • Un plugin peut diagnostiquer la présence/absence d’un outillage externe de façon structurée.
  • Le diagnostic est assez générique pour servir plusieurs stacks.
  • La doc SDK montre un cas simple de détection d’exécutable/version.