---
issueRef: "#129"
version: 6
updatedBy: {"kind":"user"}
updatedAt: 1785881187631
---
## 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.