---
issueRef: "#128"
version: 4
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
updatedAt: 1785670260985
---
## 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.