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.4 KiB
Markdown
31 lines
1.4 KiB
Markdown
---
|
||
issueRef: "#130"
|
||
version: 6
|
||
updatedBy: {"kind":"user"}
|
||
updatedAt: 1785881187639
|
||
---
|
||
## Problème
|
||
Un plugin de développement doit souvent lire ou modifier des documents structurés. Sans primitive publique, chaque plugin doit réimplémenter parsing, validation et patching, avec un risque élevé de corruption ou d’incohérence.
|
||
|
||
## Pourquoi c’est global
|
||
Le besoin concerne JSON, YAML, TOML, XML, propriétés, DSL de config, et potentiellement d’autres formats. Android n’est qu’un consommateur parmi d’autres.
|
||
|
||
## Ce que ce ticket doit produire
|
||
Une API publique de documents/config structurés permettant idéalement :
|
||
- lecture d’un document typé ou semi-structuré
|
||
- édition contrôlée/patch ciblé
|
||
- sérialisation stable
|
||
- erreurs structurées
|
||
- capacité d’évolution format par format
|
||
|
||
## Dépendances
|
||
- Dépend de `#124` car il faut d’abord un accès fichier/workspace public.
|
||
|
||
## Garde-fous
|
||
- Commencer petit si nécessaire; ne pas promettre tous les formats d’un coup.
|
||
- Préférer une abstraction extensible plutôt qu’un parser universel monolithique.
|
||
- Ne pas embarquer des helpers Android-only.
|
||
|
||
## Critères d’acceptation
|
||
- Le SDK expose une primitive réutilisable pour lire et mettre à jour un document de config sans bricolage spécifique par plugin.
|
||
- Le contrat précise clairement quels formats sont supportés dans le premier lot. |