IdeA/carnet.md at 0914a77d9fa70dde9bfebf00a4fcec67e552abe2

Files

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.3 KiB

Raw Blame History

issueRef, version, updatedBy, updatedAt

issueRef

version

updatedBy

updatedAt

#129

kind
user

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.

1.3 KiB Raw Blame History Unescape Escape