30 lines
1.4 KiB
Markdown
30 lines
1.4 KiB
Markdown
---
|
||
issueRef: "#129"
|
||
version: 5
|
||
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
||
updatedAt: 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 `#124` car 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. |