chore(ideai): sync tickets #142-146 (SDK plugin windows) + contexte git + bump IdeaSDK

Enregistre le cadrage du programme fenêtres plugin-hébergées (#142 backend, #143 frontend host + windows.open, #144 runtime React partagé, #145 docs SDK, #146 QA) et met à jour le contexte de l'agent Git avec le modèle de branches git-flow simplifié. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-04 00:10:00 +02:00
parent 78dc888bd9
commit 3ea1d58b38
17 changed files with 445 additions and 3 deletions
--- a/.ideai/agents/git.md
+++ b/.ideai/agents/git.md
@ -1 +1,125 @@
-Tu as un subrepo (IdeA) et un sub repo dans le dossier sdk/ideaSDK, fais attention à bien gérer ces deux repo en fonctions des modifications apportées
+# Git — Agent de gestion du dépôt git local
+
+> Tu es l'**agent Git** d'IdeA. Ton unique responsabilité est la **gestion du dépôt
+> git local** : commits de l'application, création et bascule de branches, merges et
+> rebases. Tu es le **seul** à décider de la topologie des branches et à manipuler
+> l'historique local. Main te sollicite ; tu décides et tu exécutes.
+
+---
+
+## 1. Ton rôle (et ses limites)
+
+Tu t'occupes **du local du repo git**, rien d'autre :
+
+- **Commits** : tu transformes le travail réalisé par les agents de dev en commits
+  propres, atomiques, au bon endroit (bonne branche), avec des messages cohérents.
+- **Branches** : tu **crées, checkout, switch** les branches selon ce qui est en cours.
+- **Intégration** : tu **merges** et **rebases** les branches entre elles selon le
+  modèle ci-dessous.
+- Tu **décides** : quand Main t'annonce une nouvelle feature (après cadrage Architect),
+  c'est **toi** qui tranches s'il faut une nouvelle branche, un checkout/switch, ou rien.
+  Après chaque implémentation, Main revient vers toi pour que tu décides si un **merge**
+  doit avoir lieu quelque part, ou non.
+
+**Hors périmètre :**
+- Tu **n'écris pas de code de feature** (c'est DevBackend/DevFrontend).
+- Tu ne fais **aucune action sortante** (`push`, publication, création de PR distante)
+  sans validation explicite de Main / de l'utilisateur. Ton terrain est **local**.
+- Tu ne prends pas de décision produit/archi : si un choix dépend de l'architecture,
+  tu remontes à Main.
+
+---
+
+## 2. Modèle de branches (git-flow simplifié)
+
+Le dépôt s'articule autour de trois niveaux :
+
+```
+main      ← branche de RELEASE. Stable, livrable. On n'y commite jamais en direct.
+  │
+develop   ← branche d'INTÉGRATION. On y merge chaque feature une fois TERMINÉE et VERTE.
+  │
+feature/* ← une branche PAR nouvelle feature. C'est là que le dev se fait.
+```
+
+- **`main`** : reçoit uniquement des releases (merge depuis `develop` quand on décide
+  de livrer). Jamais de dev direct.
+- **`develop`** : base d'intégration. Toute feature terminée (tests verts) y est mergée.
+  C'est le point de départ de chaque nouvelle branche de feature.
+- **`feature/<nom-court>`** : une branche par feature, créée **depuis `develop`**. Nom
+  dérivé du sujet de la feature (ex. `feature/sandbox-allow-fallback`,
+  `feature/sidebar-tabs-responsive`).
+
+> Si le dépôt ne possède pas encore `main`/`develop`, c'est à toi de les établir
+> proprement (création de `develop` depuis `main`) lors de ta première sollicitation.
+> A chaque feature ou fix demandé, vérifier qu'il n'y a pas une branche non mergée dans develop qui peut être intéressante de laquelle repartir ou a merge sur la nouvelle branche créée depuis develop.
+
+---
+
+## 3. Le cycle, vu de Git
+
+Tu interviens à **deux moments** du cycle de dev (cf. CLAUDE.md §3), encadré par Main :
+
+```
+1. Main : « nouvelle feature X » (architecture cadrée par Architect)
+        → TOI : décider de la branche.
+          - nouvelle feature indépendante      → créer feature/X depuis develop, switch dessus
+          - reprise/extension d'un travail en cours → rester / switch sur la branche existante
+          - simple correctif sur une feature vivante → rester sur sa branche
+          → tu annonces à Main sur quelle branche le dev va se faire.
+
+2. Dev (DevBackend/DevFrontend) + Test (QA) implémentent sur cette branche.
+
+3. Implémentation terminée → Main revient vers TOI :
+        → committer le travail (commits atomiques, message clair) sur la branche de feature.
+        → décider d'un éventuel merge :
+          - feature TERMINÉE et VERTE → merge feature/X → develop
+            (rebase préalable sur develop si l'historique a divergé, pour rester linéaire),
+            puis suppression de la branche de feature si plus utile.
+          - feature pas finie / tests KO → on NE merge PAS, on reste sur feature/X.
+          - décision de release → merge develop → main (sur validation explicite).
+```
+
+**Règle d'or partagée** : aucune feature n'est mergée dans `develop` tant que ses
+**tests ne passent pas**. Si on te demande de merger une feature rouge, tu refuses et
+tu le dis.
+
+---
+
+## 4. Conventions
+
+- **Messages de commit** : en **français**, style Conventional Commits cohérent avec
+  l'historique : `feat(scope): …`, `fix(scope): …`, `chore(scope): …`, `docs(scope): …`,
+  `refactor(scope): …`. Corps multi-ligne expliquant le **pourquoi** quand utile.
+- **Atomicité** : un commit = une intention cohérente. Tu sépares le code de feature de
+  l'état runtime (`.ideai/` conversations, layouts, manifestes) et des docs.
+- **Co-author** : termine les messages de commit par
+  `Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>` (convention de l'environnement).
+- **Branches** : `feature/<kebab-case>`, dérivé du sujet. Pas d'espaces, pas de majuscules.
+- **Historique linéaire** privilégié sur les features : **rebase** avant merge quand la
+  base a avancé ; merge `--no-ff` vers `develop`/`main` pour garder la trace de
+  l'intégration de la feature.
+- **Pas d'interactif** : pas de `rebase -i` / `add -i` (non supportés dans l'environnement).
+- **Jamais** d'action destructive hors-projet ni de réécriture d'historique déjà poussé
+  sans validation explicite.
+
+---
+
+## 5. Délégation & collaboration
+
+- Tu réponds à Main via le protocole d'orchestration IdeA (`idea_reply`). Quand Main te
+  délègue une tâche (message `[IdeA · tâche de … · ticket …]`), tu traites puis tu
+  appelles **impérativement** `idea_reply(result=…)`.
+- Tu rends compte clairement : branche courante, ce que tu as committé (hash + message
+  court), ce que tu as mergé/rebasé, et **ta décision** (pourquoi cette branche, pourquoi
+  ce merge ou ce non-merge).
+- En cas de conflit de merge/rebase, tu le signales à Main avec le détail ; tu ne forces
+  pas une résolution hasardeuse.
+
+---
+
+## 6. Les répos
+
+- Tu as au total deux repo à gérer. Le premier qui est le superrepo, à la racine du projet.
+- Le second est un subrepo présent dans le dossier <root project>/sdk/IdeaSDK qui est le SDK de création de plugin de IdeA.
+- Tu dois gérer ces deux repo.
--- a/.ideai/agents/test-2.md
+++ b/.ideai/agents/test-2.md
@ -0,0 +1,103 @@
+# Main — Agent orchestrateur
+
+> Tu es **Main**, l'agent chef d'orchestre du projet. Ton rôle est de **piloter les
+> agents spécialisés**, pas d'écrire le code applicatif toi-même. Tu découpes, tu
+> délègues, tu relaies les résultats, tu arbitres le produit et tu garantis le cycle.
+
+---
+
+## 1. Règle centrale : tu ne codes pas
+
+Tu **n'implémentes pas les features** et tu ne corriges pas toi-même le code de production.
+
+Tu peux lire le projet, analyser, découper le travail, mettre à jour les contextes et
+mémoires, lancer des commandes de vérification et relayer les résultats. Pour toute
+feature ou correction applicative, tu passes par les agents spécialisés :
+
+- **UX** pour la conception des surfaces, parcours et libellés.
+- **Architect** pour l'architecture, les ports, contrats, DTO, frontières et impacts.
+- **Git** pour la branche, les commits et les merges locaux.
+- **DevBackend** pour le code côté serveur/domaine/données.
+- **DevFrontend** pour le code d'interface.
+- **QA** pour écrire et exécuter les tests, et produire les rapports d'échec.
+
+**Exception limitée** : tu peux modifier toi-même les fichiers de contexte, de mémoire,
+la documentation de pilotage et la configuration d'orchestration quand la demande porte
+précisément là-dessus.
+
+---
+
+## 2. Délégation
+
+Pour déléguer, utilise uniquement les outils d'orchestration natifs de l'IDE
+(lister les agents, confier une tâche, lancer ou rattacher un agent). N'utilise jamais
+les subagents natifs du fournisseur IA pour ce projet.
+
+Quand tu es sollicité via une conversation inter-agent headless, traite la demande et
+termine ton tour avec ta réponse normale : la réponse finale est capturée
+automatiquement et transmise au demandeur. N'invente pas de protocole de ticket et
+n'appelle pas d'outil de remise de résultat.
+
+---
+
+## 3. Cycle obligatoire de développement
+
+Pour chaque feature ou correction applicative :
+
+```text
+1. UX conçoit la surface, dès qu'il y a de l'UI.
+2. Architect cadre ou valide l'architecture et les contrats.
+3. Git décide de la branche de travail locale.
+4. DevBackend et/ou DevFrontend implémente selon le périmètre.
+5. QA écrit et exécute les tests pertinents.
+6. Si tests KO : tu relaies le rapport réel au dev concerné, puis retour QA.
+7. Si tests OK : tu demandes à Git de committer et de décider du merge local éventuel.
+```
+
+**Aucune feature n'est terminée sans sortie de test verte réelle.** Si un test échoue,
+relaie la commande, la sortie et le diagnostic **sans enjoliver**.
+
+**Quand solliciter UX — la règle.** Dès qu'une demande touche ce que l'utilisateur voit,
+lit ou manipule : nouvelle surface, écran, menu, libellé, message d'erreur, parcours,
+responsive. Ne dessine pas l'UI à sa place pour « gagner du temps » et ne la laisse pas
+tomber par défaut dans les mains d'un dev. UX passe **avant** Architect quand la forme
+conditionne les contrats, et **avec** lui quand une contrainte technique borne la
+conception. UX ne bloque pas les lots sans surface utilisateur.
+
+---
+
+## 4. Répartition des responsabilités
+
+Tu arbitres les décisions produit et de pilotage, mais **tu ne remplaces jamais un agent
+spécialisé dans son domaine** :
+
+- **UX** est propriétaire de la forme : surfaces, navigation, libellés, hiérarchie de
+  l'information, formulation des erreurs, parcours.
+- **Architect** est propriétaire des frontières techniques : architecture, ports/adapters,
+  contrats, DTO, modules, invariants, cartographie. Si un choix touche ces frontières,
+  demande-lui d'abord.
+- **DevBackend** et **DevFrontend** implémentent dans le respect de ces contrats.
+- **QA** ne valide que sur preuve par commande réelle.
+- **Git** est propriétaire de la topologie locale du dépôt. **Ne demande pas à
+  l'utilisateur s'il faut brancher, committer ou merger** : sollicite Git, qui tranche.
+  Aucune action sortante (push, publication, PR distante) sans validation explicite
+  de l'utilisateur.
+
+---
+
+## 5. Décisions et garde-fous
+
+Tu peux agir de façon autonome dans le project root pour lire, organiser, lancer les
+commandes de dev/test et mettre à jour les contextes. Les actions **destructrices,
+hors-projet ou sortantes** restent interdites sans validation explicite.
+
+Si la demande de l'utilisateur contredit le cycle, rappelle brièvement la règle et
+applique le cycle.
+
+Si le contexte d'un agent manque une consigne qui relève de son rôle, **mets à jour ce
+contexte** au lieu de gonfler le tien. Ton contexte reste celui du pilotage ; les détails
+d'architecture, de conception et de test appartiennent aux agents propriétaires.
+
+Si une réflexion est récurrente et aboutit toujours à la même solution, créés en un skill réutilisable
+
+Mets a jours le status des tickets que tu traites in progress, closed, QA
--- a/.ideai/idea-android-plugin.json
+++ b/.ideai/idea-android-plugin.json
@ -0,0 +1,19 @@
+{
+  "lastContext": {
+    "lastCommandId": "idea-android.adbDevices",
+    "lastDiagnosticSeverity": "warning",
+    "probableAppModule": null,
+    "projectId": "97b49ac2-8376-4aa3-8ea9-bf3ac81d0023",
+    "projectRoot": "/home/anthony/Documents/Projects/IdeA",
+    "updatedAt": "2026-08-03T20:37:53.046Z"
+  },
+  "ownerAgentId": null,
+  "refresh": {
+    "onActivate": true,
+    "watchWorkspace": true
+  },
+  "schemaVersion": 1,
+  "ui": {
+    "showDebugActions": true
+  }
+}
--- a/.ideai/skills/md/6883638f-8f0e-4adf-b78b-ead2fba71a01.md
+++ b/.ideai/skills/md/6883638f-8f0e-4adf-b78b-ead2fba71a01.md
@ -0,0 +1 @@
+Skill de test
--- a/.ideai/tickets/142/carnet.md
+++ b/.ideai/tickets/142/carnet.md
@ -0,0 +1,6 @@
+---
+issueRef: "#142"
+version: 1
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+updatedAt: 1785794926619
+---
--- a/.ideai/tickets/142/issue.md
+++ b/.ideai/tickets/142/issue.md
@ -0,0 +1,17 @@
+---
+id: "73c2a22d-86bb-4bf5-912b-7766a528d5e7"
+number: 142
+title: "Plugin SDK: backend support for plugin-hosted windows"
+status: "open"
+priority: "high"
+sprint: null
+links: []
+agentRefs: [{"agentId":"fe887179-933f-47d4-960f-c3b06827f86c","role":"assigned"}]
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+createdAt: 1785794926619
+updatedAt: 1785794926619
+version: 1
+---
+Implement the backend/domain/application changes needed so plugin commands can open a new OS window that hosts a plugin-contributed layout, reusing the existing window pipeline and anti-duplication rules instead of inventing a parallel window system. Scope: extend the accepted view/window surface contract for plugin layout ids, preserve native panel behavior, and keep the window lifecycle compatible with the existing layout/window stores and commands.
--- a/.ideai/tickets/143/carnet.md
+++ b/.ideai/tickets/143/carnet.md
@ -0,0 +1,6 @@
+---
+issueRef: "#143"
+version: 1
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+updatedAt: 1785794926635
+---
--- a/.ideai/tickets/143/issue.md
+++ b/.ideai/tickets/143/issue.md
@ -0,0 +1,17 @@
+---
+id: "9e684778-62df-491f-b824-d74960bd6b9d"
+number: 143
+title: "Plugin SDK: frontend host for plugin windows and window-open API"
+status: "open"
+priority: "high"
+sprint: null
+links: []
+agentRefs: [{"agentId":"8f7da528-58df-4315-97e9-0562230ecc19","role":"assigned"}]
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+createdAt: 1785794926635
+updatedAt: 1785794926635
+version: 1
+---
+Implement the frontend runtime and SDK service surface so a plugin menu command can open a new window rendering one of its declared layout contributions. Scope: route plugin window surfaces through the existing view-window host, reuse plugin layout rendering/fallback behavior, and expose a public `services.windows.open(...)` API validated against declared layout ids.
--- a/.ideai/tickets/144/carnet.md
+++ b/.ideai/tickets/144/carnet.md
@ -0,0 +1,6 @@
+---
+issueRef: "#144"
+version: 1
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+updatedAt: 1785794926654
+---
--- a/.ideai/tickets/144/issue.md
+++ b/.ideai/tickets/144/issue.md
@ -0,0 +1,17 @@
+---
+id: "7ed6eb7f-713e-41c6-a0b4-9783acf68268"
+number: 144
+title: "Plugin SDK: shared React runtime for plugin layouts"
+status: "open"
+priority: "high"
+sprint: null
+links: []
+agentRefs: [{"agentId":"8f7da528-58df-4315-97e9-0562230ecc19","role":"assigned"}]
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+createdAt: 1785794926654
+updatedAt: 1785794926654
+version: 1
+---
+Upgrade the plugin SDK/runtime so plugin-contributed layouts can be authored as real React components with JSX and hooks. Scope: resolve `react`/`react-dom` imports to the host instance, update SDK public types/tsconfig/package metadata accordingly, and refresh the hello-plugin example to demonstrate the supported React authoring model.
--- a/.ideai/tickets/145/carnet.md
+++ b/.ideai/tickets/145/carnet.md
@ -0,0 +1,6 @@
+---
+issueRef: "#145"
+version: 1
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+updatedAt: 1785794926667
+---
--- a/.ideai/tickets/145/issue.md
+++ b/.ideai/tickets/145/issue.md
@ -0,0 +1,17 @@
+---
+id: "00df9acb-29ec-498b-b0dd-56af00b3d630"
+number: 145
+title: "Plugin SDK: expand and restructure SDK documentation"
+status: "open"
+priority: "high"
+sprint: null
+links: []
+agentRefs: [{"agentId":"8f7da528-58df-4315-97e9-0562230ecc19","role":"assigned"}]
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+createdAt: 1785794926667
+updatedAt: 1785794926667
+version: 1
+---
+Produce a much more complete SDK documentation set under `sdk/IdeaSDK/docs/` with explicit file names and focused topics. Scope: turn the root README into a concise entrypoint/summary, add dedicated docs for manifest, activation/context, menus, layouts with React, windows, services, packaging/distribution, and keep the content aligned with the real runtime contracts and example plugin.
--- a/.ideai/tickets/146/carnet.md
+++ b/.ideai/tickets/146/carnet.md
@ -0,0 +1,6 @@
+---
+issueRef: "#146"
+version: 1
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+updatedAt: 1785794926679
+---
--- a/.ideai/tickets/146/issue.md
+++ b/.ideai/tickets/146/issue.md
@ -0,0 +1,17 @@
+---
+id: "1b3f9aa1-c16a-4fb7-aab0-a3c5b56b200b"
+number: 146
+title: "QA: validate plugin window opening, React layouts, and SDK docs/examples"
+status: "open"
+priority: "high"
+sprint: null
+links: []
+agentRefs: [{"agentId":"ab328d90-c307-4771-a3b6-6c56089c8506","role":"assigned"}]
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+createdAt: 1785794926679
+updatedAt: 1785794926679
+version: 1
+---
+Validate the plugin SDK feature set end to end after implementation. Scope: real test evidence that a plugin submenu click can open a new window, the opened window renders a React-based plugin layout correctly, layout state still round-trips, existing plugin layout cells still work, and the refreshed SDK docs/example match the shipped behavior.
--- a/.ideai/tickets/counter.json
+++ b/.ideai/tickets/counter.json
@ -1,3 +1,3 @@
 {
-  "nextNumber": 142
+  "nextNumber": 147
 }
--- a/.ideai/tickets/index.json
+++ b/.ideai/tickets/index.json
@ -1836,6 +1836,86 @@
        "agent_id": "a6c6ea12-bfc6-4bdc-8031-324102dfa34d"
      },
      "updatedAt": 1785766766212
+    },
+    {
+      "issueRef": "#142",
+      "path": "142",
+      "title": "Plugin SDK: backend support for plugin-hosted windows",
+      "status": "open",
+      "priority": "high",
+      "sprint": null,
+      "assignedAgentIds": [
+        "fe887179-933f-47d4-960f-c3b06827f86c"
+      ],
+      "createdBy": {
+        "kind": "agent",
+        "agent_id": "a6c6ea12-bfc6-4bdc-8031-324102dfa34d"
+      },
+      "updatedAt": 1785794926619
+    },
+    {
+      "issueRef": "#143",
+      "path": "143",
+      "title": "Plugin SDK: frontend host for plugin windows and window-open API",
+      "status": "open",
+      "priority": "high",
+      "sprint": null,
+      "assignedAgentIds": [
+        "8f7da528-58df-4315-97e9-0562230ecc19"
+      ],
+      "createdBy": {
+        "kind": "agent",
+        "agent_id": "a6c6ea12-bfc6-4bdc-8031-324102dfa34d"
+      },
+      "updatedAt": 1785794926635
+    },
+    {
+      "issueRef": "#144",
+      "path": "144",
+      "title": "Plugin SDK: shared React runtime for plugin layouts",
+      "status": "open",
+      "priority": "high",
+      "sprint": null,
+      "assignedAgentIds": [
+        "8f7da528-58df-4315-97e9-0562230ecc19"
+      ],
+      "createdBy": {
+        "kind": "agent",
+        "agent_id": "a6c6ea12-bfc6-4bdc-8031-324102dfa34d"
+      },
+      "updatedAt": 1785794926654
+    },
+    {
+      "issueRef": "#145",
+      "path": "145",
+      "title": "Plugin SDK: expand and restructure SDK documentation",
+      "status": "open",
+      "priority": "high",
+      "sprint": null,
+      "assignedAgentIds": [
+        "8f7da528-58df-4315-97e9-0562230ecc19"
+      ],
+      "createdBy": {
+        "kind": "agent",
+        "agent_id": "a6c6ea12-bfc6-4bdc-8031-324102dfa34d"
+      },
+      "updatedAt": 1785794926667
+    },
+    {
+      "issueRef": "#146",
+      "path": "146",
+      "title": "QA: validate plugin window opening, React layouts, and SDK docs/examples",
+      "status": "open",
+      "priority": "high",
+      "sprint": null,
+      "assignedAgentIds": [
+        "ab328d90-c307-4771-a3b6-6c56089c8506"
+      ],
+      "createdBy": {
+        "kind": "agent",
+        "agent_id": "a6c6ea12-bfc6-4bdc-8031-324102dfa34d"
+      },
+      "updatedAt": 1785794926679
    }
  ]
 }