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>
31 lines
1.2 KiB
Markdown
31 lines
1.2 KiB
Markdown
---
|
||
issueRef: "#128"
|
||
version: 5
|
||
updatedBy: {"kind":"user"}
|
||
updatedAt: 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. |