36 lines
1.7 KiB
Markdown
36 lines
1.7 KiB
Markdown
---
|
||
issueRef: "#126"
|
||
version: 7
|
||
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
||
updatedAt: 1785668062783
|
||
---
|
||
## 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. |