IdeA/carnet.md at a3d94d4d5e532e25353a204906121b42ab04abc6

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

#127

kind
user

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.

1.3 KiB Raw Blame History Unescape Escape