Blomios
ecad746c66
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>
35 lines
1.3 KiB
Markdown
35 lines
1.3 KiB
Markdown
---
|
||
issueRef: "#127"
|
||
version: 5
|
||
updatedBy: {"kind":"user"}
|
||
updatedAt: 1785881187615
|
||
---
|
||
## Problème
|
||
Sans bus d’événements ou API de watch publique, un plugin doit poller l’état du host ou du workspace pour se tenir à jour. C’est coûteux, fragile et peu réactif.
|
||
|
||
## Pourquoi c’est global
|
||
Tout plugin de dev outillé peut avoir besoin de réagir à :
|
||
- changement de fichier
|
||
- fin/échec d’une tâche
|
||
- changement de projet courant
|
||
- autres événements système ou host pertinents
|
||
|
||
## Ce que ce ticket doit produire
|
||
Une API publique d’abonnement permettant au minimum :
|
||
- souscription/désinscription propre
|
||
- typage minimal des événements publics
|
||
- événements documentés et versionnables
|
||
- stratégie claire sur rétention/perte d’événements
|
||
|
||
## Contraintes d’architecture
|
||
- Exposer uniquement des événements publics stables.
|
||
- Ne pas refléter brut de décoffrage les événements internes du host.
|
||
- Bien définir les garanties: best effort vs livraison fiable.
|
||
|
||
## Non-objectifs
|
||
- Pas de protocole temps réel cross-process complexe si non nécessaire.
|
||
- Pas d’événements spécifiques Android.
|
||
|
||
## Critères d’acceptation
|
||
- Un plugin peut se mettre à jour sur changements du workspace/host sans polling permanent.
|
||
- L’API de subscription est proprement disposable et documentée. |