chore(tickets): mise à jour index et tickets SDK plugins #123-#130

.ideai/tickets/123/carnet.md

@@ -0,0 +1,39 @@
+---
+issueRef: "#123"
+version: 4
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedAt: 1785670261241
+---
+## Contexte
+Le besoin initial vient d’un futur plugin orienté développement Android, mais le périmètre validé pour ce chantier est strictement **SDK générique**. L’objectif n’est pas d’ajouter des API Android-first, mais de combler les trous du SDK public qui empêchent aujourd’hui tout plugin de développement un peu sérieux.
+
+## Ce qui existe déjà
+- Manifest public `idea-plugin.json`
+- Runtime `activate(ctx)`
+- `commands`, `storage`, `logger`
+- `services.workspace`, `services.tasks`, `services.terminal`
+- Contributions `menus`, `menuItems`, `layouts`, `mcpServers`
+
+## Problème
+Le SDK public actuel est volontairement minimal. Il permet des plugins simples, mais pas un plugin d’outillage qui doit agir sur un workspace, lancer des outils externes, réagir aux événements du host, afficher une UI riche, ou analyser la structure d’un projet.
+
+## Décision de cadrage
+Découper le besoin en tickets transverses, indépendants autant que possible.
+
+Ordre de priorité retenu :
+1. `#124` API fichiers/workspace
+2. `#125` API lancement de commandes et tâches
+3. `#126` API découverte/validation d’outillage externe
+4. `#127` API d’événements et de watch
+5. `#128` runtime UI/layout publique
+6. `#129` API d’analyse/requête de structure projet
+7. `#130` API de documents de configuration structurés
+
+## Garde-fous
+- Pas d’API spécifique Android dans ce lot.
+- Préserver une frontière SDK public vs runtime interne.
+- Favoriser des primitives génériques réutilisables pour Android, iOS, Node, Python, Docker, etc.
+- Éviter de forcer les plugins à dépendre de casts ad hoc ou d’objets runtime internes.
+
+## Définition de done du parapluie
+Le parapluie est clôturable quand les tickets enfants retenus pour le MVP sont livrés ou explicitement re-scopeés avec arbitrage.

.ideai/tickets/123/issue.md

@@ -0,0 +1,17 @@
+---
+id: "0013caf7-bbc9-439f-82b2-9d23ed9e901a"
+number: 123
+title: "SDK plugins: combler les capacités globales manquantes pour les plugins de développement outillés"
+status: "qa"
+priority: "high"
+sprint: null
+links: []
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+createdAt: 1785662012603
+updatedAt: 1785670261241
+version: 4
+---
+Ticket parapluie pour structurer l’extension du SDK public des plugins IdeA afin de supporter des plugins de développement avancés sans introduire d’API métier spécifiques à une stack donnée. Le besoin initial vient du cas Android, mais le périmètre doit rester strictement transversal.

.ideai/tickets/124/carnet.md

@@ -0,0 +1,39 @@
+---
+issueRef: "#124"
+version: 4
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedAt: 1785666067073
+---
+## Problème
+`WorkspaceService` public expose aujourd’hui seulement le projet courant, son root, et la lecture/écriture du contexte Markdown IdeA. Cela ne suffit pas pour un plugin de développement qui doit lire, écrire, lister ou surveiller les fichiers d’un projet.
+
+## Pourquoi c’est global
+Ce besoin n’a rien de spécifique à Android. Tout plugin de dev outillé doit pouvoir manipuler le workspace : configs, manifests, scripts, sources, fichiers générés, assets, etc.
+
+## Ce que ce ticket doit produire
+Une API publique de workspace/fichiers permettant au minimum :
+- lecture de fichier texte/binaire
+- écriture atomique ou contrôlée
+- listing de répertoires
+- existence/stat basiques
+- résolution sûre de chemins dans le project root
+- capacité de watch ou point d’extension compatible avec `#127`
+
+## Contraintes d’architecture
+- API strictement publique côté SDK TypeScript.
+- Aucun accès direct aux objets runtime internes.
+- Respect du sandboxing et du project root.
+- Contrat clair sur les erreurs, encodages, chemins hors-root et fichiers absents.
+
+## Non-objectifs
+- Pas de parser Gradle/XML/JSON dans ce ticket.
+- Pas d’analyse sémantique du projet.
+- Pas de conventions Android codées en dur.
+
+## Dépendances
+- Bloque `#126`, `#129`, `#130`.
+
+## Critères d’acceptation
+- Un plugin peut lire/écrire/lister dans le workspace sans cast interne.
+- Le contrat gère explicitement les chemins invalides/hors-root.
+- La documentation SDK montre un exemple simple de manipulation de fichiers.

.ideai/tickets/124/issue.md

@@ -0,0 +1,17 @@
+---
+id: "639787e1-83b5-49b7-a89f-3a6985129163"
+number: 124
+title: "SDK plugins: exposer une API publique d’accès fichiers/workspace"
+status: "qa"
+priority: "critical"
+sprint: null
+links: [{"target":"#123","kind":"blocks"}]
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+createdAt: 1785662026640
+updatedAt: 1785666067073
+version: 4
+---
+Ajouter au SDK plugin une API publique de lecture/écriture/listing/watch dans le workspace projet, distincte du simple accès au contexte Markdown IdeA.

.ideai/tickets/125/carnet.md

@@ -0,0 +1,40 @@
+---
+issueRef: "#125"
+version: 4
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedAt: 1785667057177
+---
+## Problème
+Le SDK public permet seulement :
+- d’observer/contrôler des background tasks existantes
+- d’ouvrir un PTY interactif
+
+Il manque une API publique pour **démarrer** une commande/outillage externe de façon intégrée à IdeA.
+
+## Pourquoi c’est global
+Le besoin est transversal à tous les plugins de développement : build, test, lint, génération, outils CLI, pipelines locaux, simulateurs, wrappers maison.
+
+## Ce que ce ticket doit produire
+Une API publique de lancement de commandes/tâches permettant au minimum :
+- exécuter une commande avec `cwd`, args, env
+- choisir un mode tracked/background task plutôt qu’un PTY brut
+- suivre statut, exit code, stdout/stderr
+- annuler / éventuellement relancer
+- corréler le run avec le modèle Work d’IdeA
+
+## Contraintes d’architecture
+- Ne pas confondre terminal interactif et task runner.
+- Contrat stable sur environnement, cwd, timeouts éventuels, sortie et erreurs.
+- Le plugin ne doit pas avoir à bricoler une session PTY pour lancer un build.
+
+## Non-objectifs
+- Pas de sémantique Android/Gradle/adb.
+- Pas d’orchestration multi-étapes spécifique à une stack.
+
+## Dépendances
+- Bloque `#126`.
+
+## Critères d’acceptation
+- Un plugin peut lancer une commande externe sans passer par un cast interne ni un PTY interactif.
+- L’exécution remonte un état observable et un résultat terminal clair.
+- Le contrat est documenté côté SDK avec exemple de commande simple.

.ideai/tickets/125/issue.md

@@ -0,0 +1,17 @@
+---
+id: "78bb45fb-6320-4d75-8db2-1e2a9591219f"
+number: 125
+title: "SDK plugins: exposer une API publique de lancement de commandes et tâches"
+status: "qa"
+priority: "critical"
+sprint: null
+links: [{"target":"#123","kind":"blocks"}]
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+createdAt: 1785662026655
+updatedAt: 1785667057177
+version: 4
+---
+Ajouter au SDK plugin une API publique pour lancer des commandes/outils externes et suivre leur exécution comme tâches IdeA, au-delà de l’observation des tâches existantes et du simple PTY interactif.

.ideai/tickets/126/carnet.md

@@ -0,0 +1,36 @@
+---
+issueRef: "#126"
+version: 7
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedAt: 1785668062783
+---
+## Problème
+Un plugin de dev a souvent besoin de savoir si un outillage externe existe, où il se trouve, quelle version est installée, et si l’environnement est valide. Le SDK public n’expose pas aujourd’hui cette capacité comme primitive générique.
+
+## Pourquoi c’est global
+Ce besoin vaut pour Android SDK, Java, Node, Python, Docker, Go, Rust toolchain, etc. Le ticket doit fournir une abstraction générique de découverte/validation d’outillage, pas une API dédiée Android.
+
+## Ce que ce ticket doit produire
+Une API publique permettant idéalement :
+- résolution d’un exécutable ou d’une toolchain par nom/id
+- lecture de version
+- inspection de variables d’environnement pertinentes
+- validation de prérequis déclaratifs
+- restitution d’un diagnostic structuré exploitable par une UI plugin
+
+## Contraintes d’architecture
+- La source de vérité peut s’appuyer sur fichiers, env et exécution d’outils, mais l’API exposée doit rester stable et agnostique.
+- Ne pas figer de modèle métier Android.
+
+## Dépendances
+- Dépend de `#124` pour l’accès workspace/config.
+- Dépend de `#125` pour l’exécution contrôlée des commandes de détection.
+
+## Non-objectifs
+- Pas de gestion d’émulateur/device manager.
+- Pas d’installation automatique d’une toolchain dans ce ticket.
+
+## Critères d’acceptation
+- Un plugin peut diagnostiquer la présence/absence d’un outillage externe de façon structurée.
+- Le diagnostic est assez générique pour servir plusieurs stacks.
+- La doc SDK montre un cas simple de détection d’exécutable/version.

.ideai/tickets/126/issue.md

@@ -0,0 +1,17 @@
+---
+id: "51d4f4b0-4482-4400-a0d5-9f88471581f0"
+number: 126
+title: "SDK plugins: exposer une API publique de découverte/validation d’outillage externe"
+status: "qa"
+priority: "high"
+sprint: null
+links: [{"target":"#123","kind":"blocks"},{"target":"#124","kind":"dependsOn"},{"target":"#125","kind":"dependsOn"}]
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+createdAt: 1785662026684
+updatedAt: 1785668062783
+version: 7
+---
+Ajouter au SDK plugin une API publique pour détecter, valider et décrire des toolchains externes (exécutables, versions, variables d’environnement, prérequis) sans spécialiser le SDK pour une stack donnée.

.ideai/tickets/127/carnet.md

@@ -0,0 +1,35 @@
+---
+issueRef: "#127"
+version: 4
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedAt: 1785669121141
+---
+## 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.

.ideai/tickets/127/issue.md

@@ -0,0 +1,17 @@
+---
+id: "9b238559-9982-4a69-8795-99da8a46be1e"
+number: 127
+title: "SDK plugins: exposer une API publique d’événements et de watch"
+status: "qa"
+priority: "high"
+sprint: null
+links: [{"target":"#123","kind":"blocks"}]
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+createdAt: 1785662026701
+updatedAt: 1785669121141
+version: 4
+---
+Ajouter au SDK plugin une API publique d’abonnement aux événements utiles du host et du projet: changements de fichiers, évolution des tâches, focus projet et autres signaux nécessaires pour éviter le polling côté plugin.

.ideai/tickets/128/carnet.md

@@ -0,0 +1,31 @@
+---
+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.

.ideai/tickets/128/issue.md

@@ -0,0 +1,17 @@
+---
+id: "053f079d-1dfd-48bb-85a2-2dfa8d237999"
+number: 128
+title: "SDK plugins: typer et stabiliser la runtime UI/layout publique"
+status: "qa"
+priority: "medium"
+sprint: null
+links: [{"target":"#123","kind":"blocks"}]
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+createdAt: 1785662026717
+updatedAt: 1785670260985
+version: 4
+---
+Formaliser la surface runtime publique pour les contributions UI/layout des plugins afin d’éviter les casts ad hoc et de permettre des panneaux/plugins de dev riches sur base stable.

.ideai/tickets/129/carnet.md

@@ -0,0 +1,30 @@
+---
+issueRef: "#129"
+version: 5
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedAt: 1785666067171
+---
+## Problème
+Chaque plugin de développement devrait aujourd’hui rescanner lui-même le workspace pour reconstruire une vision de la structure projet. Cela duplique les heuristiques et rend l’écosystème fragile.
+
+## Pourquoi c’est global
+Android n’est qu’un cas parmi d’autres. Les plugins pour monorepos JS, workspaces Rust, Python multi-env, etc. ont tous besoin d’une lecture structurée minimale du projet.
+
+## Ce que ce ticket doit produire
+Une API publique d’analyse/requête permettant idéalement :
+- liste de fichiers ou sous-ensembles pertinents
+- conventions détectées
+- modules/units logiques quand connus
+- graphes simples ou métadonnées projet de base
+- résultats structurés et bornés, pas un AST universel magique
+
+## Dépendances
+- Dépend de `#124` car l’analyse repose au minimum sur l’accès contrôlé au workspace.
+
+## Non-objectifs
+- Pas d’indexation sémantique profonde de tous les langages.
+- Pas de modèle Android-only (Gradle modules, variants, etc.) dans l’API publique de base.
+
+## Critères d’acceptation
+- Un plugin peut interroger la structure du projet sans rescanner tout le disque lui-même.
+- Le contrat reste utile à plusieurs stacks et ne fuit pas des abstractions internes.

.ideai/tickets/129/issue.md

@@ -0,0 +1,17 @@
+---
+id: "550fe7ca-8a25-4529-be2e-2fd79c7ddde4"
+number: 129
+title: "SDK plugins: exposer une API publique d’analyse/requête de structure projet"
+status: "qa"
+priority: "medium"
+sprint: null
+links: [{"target":"#123","kind":"blocks"},{"target":"#124","kind":"dependsOn"}]
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+createdAt: 1785662026738
+updatedAt: 1785666067171
+version: 5
+---
+Ajouter au SDK plugin une API publique pour interroger la structure d’un projet (fichiers, modules, graphes simples, conventions détectées) sans obliger chaque plugin à rescanner le workspace depuis zéro.

.ideai/tickets/130/carnet.md

@@ -0,0 +1,31 @@
+---
+issueRef: "#130"
+version: 5
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedAt: 1785669830933
+---
+## 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.

.ideai/tickets/130/issue.md

@@ -0,0 +1,17 @@
+---
+id: "07a76880-f176-4fc8-b1d3-732a88a8c837"
+number: 130
+title: "SDK plugins: exposer une API publique de documents de configuration structurés"
+status: "qa"
+priority: "medium"
+sprint: null
+links: [{"target":"#123","kind":"blocks"},{"target":"#124","kind":"dependsOn"}]
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+createdAt: 1785662026750
+updatedAt: 1785669830933
+version: 5
+---
+Ajouter au SDK plugin une API publique pour lire/mettre à jour des documents de configuration structurés via un modèle générique plutôt que forcer chaque plugin à réimplémenter son parsing/patching.

.ideai/tickets/counter.json

@@ -1,3 +1,3 @@
 {
-  "nextNumber": 123
+  "nextNumber": 131
 }

.ideai/tickets/index.json

@@ -1594,6 +1594,118 @@
         "kind": "user"
       },
       "updatedAt": 1785592528432
+    },
+    {
+      "issueRef": "#123",
+      "path": "123",
+      "title": "SDK plugins: combler les capacités globales manquantes pour les plugins de développement outillés",
+      "status": "qa",
+      "priority": "high",
+      "sprint": null,
+      "assignedAgentIds": [],
+      "createdBy": {
+        "kind": "agent",
+        "agent_id": "a6ced819-b893-4213-b003-9e9dc79b9641"
+      },
+      "updatedAt": 1785670261241
+    },
+    {
+      "issueRef": "#124",
+      "path": "124",
+      "title": "SDK plugins: exposer une API publique d’accès fichiers/workspace",
+      "status": "qa",
+      "priority": "critical",
+      "sprint": null,
+      "assignedAgentIds": [],
+      "createdBy": {
+        "kind": "agent",
+        "agent_id": "a6ced819-b893-4213-b003-9e9dc79b9641"
+      },
+      "updatedAt": 1785666067073
+    },
+    {
+      "issueRef": "#125",
+      "path": "125",
+      "title": "SDK plugins: exposer une API publique de lancement de commandes et tâches",
+      "status": "qa",
+      "priority": "critical",
+      "sprint": null,
+      "assignedAgentIds": [],
+      "createdBy": {
+        "kind": "agent",
+        "agent_id": "a6ced819-b893-4213-b003-9e9dc79b9641"
+      },
+      "updatedAt": 1785667057177
+    },
+    {
+      "issueRef": "#126",
+      "path": "126",
+      "title": "SDK plugins: exposer une API publique de découverte/validation d’outillage externe",
+      "status": "qa",
+      "priority": "high",
+      "sprint": null,
+      "assignedAgentIds": [],
+      "createdBy": {
+        "kind": "agent",
+        "agent_id": "a6ced819-b893-4213-b003-9e9dc79b9641"
+      },
+      "updatedAt": 1785668062783
+    },
+    {
+      "issueRef": "#127",
+      "path": "127",
+      "title": "SDK plugins: exposer une API publique d’événements et de watch",
+      "status": "qa",
+      "priority": "high",
+      "sprint": null,
+      "assignedAgentIds": [],
+      "createdBy": {
+        "kind": "agent",
+        "agent_id": "a6ced819-b893-4213-b003-9e9dc79b9641"
+      },
+      "updatedAt": 1785669121141
+    },
+    {
+      "issueRef": "#128",
+      "path": "128",
+      "title": "SDK plugins: typer et stabiliser la runtime UI/layout publique",
+      "status": "qa",
+      "priority": "medium",
+      "sprint": null,
+      "assignedAgentIds": [],
+      "createdBy": {
+        "kind": "agent",
+        "agent_id": "a6ced819-b893-4213-b003-9e9dc79b9641"
+      },
+      "updatedAt": 1785670260985
+    },
+    {
+      "issueRef": "#129",
+      "path": "129",
+      "title": "SDK plugins: exposer une API publique d’analyse/requête de structure projet",
+      "status": "qa",
+      "priority": "medium",
+      "sprint": null,
+      "assignedAgentIds": [],
+      "createdBy": {
+        "kind": "agent",
+        "agent_id": "a6ced819-b893-4213-b003-9e9dc79b9641"
+      },
+      "updatedAt": 1785666067171
+    },
+    {
+      "issueRef": "#130",
+      "path": "130",
+      "title": "SDK plugins: exposer une API publique de documents de configuration structurés",
+      "status": "qa",
+      "priority": "medium",
+      "sprint": null,
+      "assignedAgentIds": [],
+      "createdBy": {
+        "kind": "agent",
+        "agent_id": "a6ced819-b893-4213-b003-9e9dc79b9641"
+      },
+      "updatedAt": 1785669830933
     }
   ]
 }