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

Raw Blame History

issueRef, version, updatedBy, updatedAt

issueRef

version

updatedBy

updatedAt

#128

kind
user

1785881187622

Problème

Le manifeste expose déjà des contributions layouts, mais la runtime publique ne formalise pas proprement l’enregistrement et le cycle de vie de ces layouts. L’exemple SDK actuel contourne la surface avec des casts ad hoc.

Pourquoi c’est global

Ce n’est pas spécifique à Android: tout plugin de dev peut vouloir afficher un panneau d’état, un tableau, un viewer de logs, une vue de diagnostic, etc.

Ce que ce ticket doit produire

Une runtime UI/layout publique stable permettant au minimum :

enregistrement typé d’un layout
props publiques documentées
cycle de vie clair
persistance/lecture de state si le host la supporte
retrait propre via disposable

Contraintes d’architecture

Pas de dépendance à des détails runtime privés.
Contrat explicite sur le rendu et la sérialisation du state plugin.

Non-objectifs

Pas d’imposer un design system plugin complet.
Pas d’API spécifique aux vues Android.

Critères d’acceptation

L’exemple SDK n’a plus besoin de cast ad hoc pour enregistrer un layout.
La surface publique suffit pour un panneau plugin de dev non trivial.

1.2 KiB Raw Blame History Unescape Escape