1.4 KiB
1.4 KiB
issueRef, version, updatedBy, updatedAt
| issueRef | version | updatedBy | updatedAt | ||||
|---|---|---|---|---|---|---|---|
| #129 | 5 |
|
1785666067171 |
Problème
Chaque plugin de développement devrait aujourd’hui rescanner lui-même le workspace pour reconstruire une vision de la structure projet. Cela duplique les heuristiques et rend l’écosystème fragile.
Pourquoi c’est global
Android n’est qu’un cas parmi d’autres. Les plugins pour monorepos JS, workspaces Rust, Python multi-env, etc. ont tous besoin d’une lecture structurée minimale du projet.
Ce que ce ticket doit produire
Une API publique d’analyse/requête permettant idéalement :
- liste de fichiers ou sous-ensembles pertinents
- conventions détectées
- modules/units logiques quand connus
- graphes simples ou métadonnées projet de base
- résultats structurés et bornés, pas un AST universel magique
Dépendances
- Dépend de
#124car l’analyse repose au minimum sur l’accès contrôlé au workspace.
Non-objectifs
- Pas d’indexation sémantique profonde de tous les langages.
- Pas de modèle Android-only (Gradle modules, variants, etc.) dans l’API publique de base.
Critères d’acceptation
- Un plugin peut interroger la structure du projet sans rescanner tout le disque lui-même.
- Le contrat reste utile à plusieurs stacks et ne fuit pas des abstractions internes.