chore(tickets): synchronise l'état runtime des tickets et de la mémoire

Clôture #114/#115/#116/#117, suppression #111, ouverture #119/#120/#121,
notes mémoire root-cause #113 et angle d'investigation #120.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
2026-07-31 23:52:33 +02:00
parent 32c257d2e1
commit 5efb026a80
21 changed files with 487 additions and 107 deletions

View File

@ -74,3 +74,5 @@
- [model-catalogue-compat-cadrage](model-catalogue-compat-cadrage.md) — Frontières hexagonales, ports, DTO, fallback et matrice de compatibilité versionnée pour l'évolution du catalogue de modèles des profils structurés Codex/Claude.
- [tickets-70-100-102-ux-surface-scoping](tickets-70-100-102-ux-surface-scoping.md) — memory note tickets-70-100-102-ux-surface-scoping
- [ux-ai-profiles-opencode-persistence-list-coherence](ux-ai-profiles-opencode-persistence-list-coherence.md) — memory note ux-ai-profiles-opencode-persistence-list-coherence
- [ticket113-controlled-args-field-rootcause](ticket113-controlled-args-field-rootcause.md) — memory note ticket113-controlled-args-field-rootcause
- [ticket120-hello-plugin-recurrence-investigation-angle](ticket120-hello-plugin-recurrence-investigation-angle.md) — memory note ticket120-hello-plugin-recurrence-investigation-angle

View File

@ -0,0 +1,20 @@
---
name: ticket113-controlled-args-field-rootcause
description: memory note ticket113-controlled-args-field-rootcause
metadata:
type: project
---
---
name: ticket113-controlled-args-field-rootcause
description: Cause racine identifiée du bug ticket #113 (espaces impossibles dans le champ Arguments supplémentaires llamacpp) et niveau de fix attendu.
metadata:
type: project
---
Root cause confirmée dans le code (2026-07-31) : `frontend/src/features/model-servers/ModelServersPanel.tsx:645-647` affiche `value={draft.args.join(" ")}` et parse via `parseArgs` (`modelServer.ts:133`, `split(/\s+/).filter(non-vide)`) à chaque `onChange`. Le state du champ est un `string[]` reconstruit en texte à chaque frappe, donc tout espace en fin de saisie ou espace double est immédiatement absorbé avant le prochain re-render : l'utilisateur ne peut jamais laisser un espace « en attente ».
Le même pattern existe à l'identique dans `frontend/src/features/first-run/FirstRunWizard.tsx:264` (même `parseArgs` importé depuis `first-run/profile.ts`) — probablement le même bug latent, non signalé par l'utilisateur mais à couvrir dans le même correctif.
**Why:** classique piège de champ contrôlé dont le state est un type dérivé (array) plutôt que la chaîne brute tapée — le round-trip parse→join efface la saisie en cours.
**How to apply:** le fix attendu est purement frontend/local : garder une valeur de saisie brute en state local (string) pendant la frappe, ne convertir vers `args: string[]` qu'à la sortie du champ (blur/submit), sans reconstruire `value` depuis `args.join(" ")` à chaque `onChange`. Aucun changement domaine/backend/DTO nécessaire — `args: string[]` reste le contrat de sortie inchangé.

View File

@ -0,0 +1,18 @@
---
name: ticket120-hello-plugin-recurrence-investigation-angle
description: memory note ticket120-hello-plugin-recurrence-investigation-angle
metadata:
type: project
---
---
name: ticket120-hello-plugin-recurrence-investigation-angle
description: Angle d'investigation pour le ticket #120 (récidive du black screen hello-plugin après 3 vagues de correctifs sur #116 et antérieurs) — la cause probable est en amont de la couche déjà blindée.
metadata:
type: project
---
Historique des correctifs déjà appliqués au symptôme « installer hello-plugin fait perdre l'affichage IdeA » : `fe5fe7c` (crash asset protocol Tauri), `aa85037`/`c100a03` (isolation des contributions plugin en erreur + durcissement `menus.ts`), `d4e61a8`/`f6685aa` (ticket #116, fermé). Constat utilisateur live au 2026-07-31 (ticket #120) : le black screen est **toujours observé** malgré ces trois vagues.
**Why:** trois correctifs successifs ciblant tous la couche « rendu des contributions plugin déjà chargées » sans faire disparaître le symptôme est un signal fort que la cause racine réelle est ailleurs — probablement en amont (flux d'installation backend : validation manifeste, copie assets, écriture manifeste projet — un panic/erreur non catché ici peut tuer le process Tauri entier, ce qu'aucune isolation frontend ne peut rattraper) ou dans le remount/reload post-install côté frontend, pas dans le rendu des contributions lui-même qui a déjà été isolé trois fois.
**How to apply:** pour #120, prioriser l'audit du chemin d'installation backend et de la frontière install→reload frontend AVANT de retoucher l'isolation des contributions (déjà traitée). Reproduire dans l'AppImage réellement rebuild (pas `pnpm dev`), pas seulement en dev — voir [[mcp-bridge-and-delegation-runtime-notes]] sur le piège du binaire qui tourne. Ne pas re-fermer le ticket sans preuve live post-fix dans le binaire réel, comme #116 l'a probablement fait à tort.

View File

@ -1,69 +0,0 @@
---
issueRef: "#111"
version: 3
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
updatedAt: 1785390694060
---
## Enquete `/tmp` IdeA — inventaire et fenetres de cleanup
### Methode
- Scan du code sur les usages `std::env::temp_dir()` / prexifes `idea-*` hors `frontend`.
- Lecture des blocs source pour separer `runtime` vs `#[cfg(test)]`.
- Verification du contenu live de `/tmp` au moment de l'analyse : aucun dossier `idea-*` visible a la racine de `/tmp` pendant ce tour.
### Conclusion courte
- Les noms cites dans le ticket (`idea-structured-session-factory-*`, `idea-web-root-*`, `idea-server-test-*`, `idea-openai-compat-*`, etc.) ne correspondent pas, dans l'etat actuel du code, a des artefacts runtime produit. Ils proviennent majoritairement de tests embarques dans les crates Rust.
- Le seul artefact runtime clair lie a IdeA/MCP trouve pendant l'analyse est le repertoire parent `idea-mcp` qui heberge les sockets Unix par projet quand le runtime tombe sur `/tmp` comme base.
- Donc le modele `un call MCP -> un dossier temp -> suppression en fin de call` n'est pas le bon modele pour la majorite des cas observes.
### Runtime reel identifie
#### 1. `idea-mcp` (runtime MCP par projet)
- Source : `crates/backend/src/mcp_endpoint.rs` et miroir `crates/app-tauri/src/mcp_endpoint.rs`.
- Role : repertoire parent des sockets Unix du serveur MCP local, ex. `<runtime-dir>/idea-mcp/<project-id>.sock`.
- Creation : a la determination du endpoint MCP du projet si le sous-dossier `idea-mcp` n'existe pas deja.
- Granularite : par projet / par listener MCP, pas par appel d'outil MCP.
- Cleanup deja present :
- le fichier socket est unlink sur fermeture propre via `reclaim_name(true)` ;
- un socket cadavre est supprime avant rebind si c'est bien un socket stale ;
- refs utiles : `crates/backend/src/lib.rs` autour de `bind_endpoint()` et `crates/backend/src/mcp_endpoint.rs`.
- Cleanup opportun :
- **pas** a la fin de chaque call MCP ;
- **oui** a la fermeture du listener / fermeture du projet pour le fichier `.sock` ;
- **oui** au prochain demarrage / prochain bind pour nettoyer un socket stale d'un crash precedent ;
- **amelioration possible** : supprimer aussi le dossier parent `idea-mcp` s'il devient vide apres drop du dernier socket, ou faire un sweep best-effort au demarrage des endpoints MCP.
- Importance : c'est le seul candidat clairement runtime et potentiellement visible sous `/tmp` si `XDG_RUNTIME_DIR` / `TMPDIR` ne sont pas utilisables et que le fallback tombe sur `/tmp`.
### Faux positifs / test-only observes
Ces prefixes existent dans le code mais dans des blocs de tests ou helpers de test. Ils ne semblent pas correspondre a des dossiers runtime utilisateur :
- `idea-openai-compat-*` : `crates/infrastructure/src/session/openai_compat.rs`
- `idea-structured-session-*` : `crates/infrastructure/src/session/mod.rs`
- `idea-web-root-*`, `idea-server-test-*`, `idea-server-lock-*`, `idea-app-data-env-*`, `idea-shared-core-*`, `idea-empty-web-*` : `crates/web-server/src/lib.rs`
- `idea-embedded-server-*` : `crates/app-tauri/src/embedded_server.rs`
- `idea-openai-mcp-tools-list-*`, `idea-openai-mcp-permissions-*`, variantes `app-tauri-*` : tests dans `crates/backend/src/openai_tools.rs` et `crates/app-tauri/src/openai_tools.rs`
- `idea-pty-sandbox-*`, `idea-landlock-*`, `idea-opencode-*`, `idea-devices-store-*`, `idea-secrets-store-*`, etc. : helpers de tests avec `Drop`/`remove_dir_all`.
### Lecture sur leur cleanup
- Dans la majorite des cas de tests lus, le cleanup nominal existe deja (`Drop`, `remove_dir_all`, `remove_file`).
- Le vrai risque residuel de ces dossiers est surtout : crash/abort de test, kill brutal, ou interruption d'une suite de tests. Dans ce cas, le residue reste dans `/tmp`.
- Comme `/tmp` est borne a 16 Go, ces residues peuvent devenir un probleme d'hygiene, mais ce n'est pas un sujet de lifecycle MCP par call ; c'est plutot un sujet de hygiene de tests / sweep de reliquats.
### Fenetres de cleanup recommandes
#### Runtime produit
- `idea-mcp/<project>.sock` : cleanup a la fermeture du listener MCP (deja en place) ; stale cleanup avant bind (deja en place).
- `idea-mcp/` parent dir : cleanup best-effort si vide apres fermeture du dernier listener, ou sweep au demarrage de l'app / ouverture projet.
#### Artefacts de tests
- Cleanup nominal dans chaque test/helper (souvent deja fait).
- Ajouter si besoin un sweep best-effort des prefixes `idea-*` generes par les tests au debut/fin des jobs de test locaux/CI.
- Ne pas melanger cela avec la logique runtime MCP : c'est un chantier distinct.
### Recommandation de perimetre pour le ticket #111
1. Cadrer `#111` sur les **artefacts runtime** visibles par l'utilisateur.
2. Traiter en priorite `idea-mcp` :
- verifier si le dossier parent vide reste parfois en place ;
- si oui, le supprimer quand il devient vide ou au prochain demarrage.
3. Ouvrir si necessaire un second ticket dedie a l'hygiene des reliquats de tests sous `/tmp`.
### Reponse a la question produit initiale
- Oui, IdeA peut produire un artefact sous `/tmp` pour le MCP runtime (`idea-mcp`), mais ce n'est pas cree par appel MCP individuel.
- Non, les dossiers cites dans la description ne semblent pas, a ce stade, etre crees par les appels MCP IdeA de production ; ils sont majoritairement issus de tests.

View File

@ -1,17 +0,0 @@
---
id: "19adb66b-34db-4c44-98b7-d6383759e90c"
number: 111
title: "Gestion tmp des outils idea"
status: "open"
priority: "medium"
sprint: null
links: []
agentRefs: []
attachments: []
createdBy: {"kind":"user"}
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
createdAt: 1785331481527
updatedAt: 1785390694060
version: 3
---
dans le dossier /tmp, je vois enormement de dossier du genre : idea-structured-session-factory-openai-e5bbdcac-0405-4ce3-be82-00d9639ee648 ou encore idea-web-root-4fbc4144-065c-4915-9e05-9f6fec20aa3b ou idea-server-test-863efbe5-5098-4f34-aab8-1ba5047f4209 ou idea-openai-compat-unreachable-f713f5fa-5469-4875-96f9-242f7913441b ou idea-openai-compat-tools-rejected-d000d319-8c11-4585-8a16-6ae8a3b45c49 ou idea-openai-compat-status-422-9fd4b27f-e0c1-4043-9fb9-72dcf8d2c2e1 ou idea-openai-compat-single-final-940b1d63-6d4a-40b0-953a-0f3279ec2bdc etc qui sont visiblement créé par IdeA. J'aiemrais que pour un maximum d'entre eux, on puisse clean ça au bon momment. Il faut donc identifier ce qui créé ce cache, puis le supprimer quand ce cache n'est plus utile.

View File

@ -1,6 +1,6 @@
---
issueRef: "#114"
version: 4
version: 5
updatedBy: {"kind":"user"}
updatedAt: 1785395923498
updatedAt: 1785509526119
---

View File

@ -2,7 +2,7 @@
id: "a7602792-21c6-40f3-852a-5200d604db9d"
number: 114
title: "[UI] un iformiser les droplist"
status: "open"
status: "closed"
priority: "medium"
sprint: "5afd6780-0f76-40d7-a10f-32ee52469d74"
links: []
@ -11,7 +11,7 @@ attachments: []
createdBy: {"kind":"user"}
updatedBy: {"kind":"user"}
createdAt: 1785395791597
updatedAt: 1785395923498
version: 4
updatedAt: 1785509526119
version: 5
---
Dans les différentes fenetres j'aimerais qu'on uniformise les droplist. C'est a dire que par exemple dans la fenetre de création de ticket, on a une droplist noire pour la selection d'un agent à lier, j'aimerais que ça soit la même droplist pour la selection du modele dans la fenetre des agents, dans la selection du template a la création d'un agent etc. Que toutes ces petites droplist dynamiques soient comme celle de selection de l'agent dans la fenetre de creation de tickets

View File

@ -0,0 +1,6 @@
---
issueRef: "#115"
version: 3
updatedBy: {"kind":"agent","agent_id":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"}
updatedAt: 1785499018589
---

View File

@ -0,0 +1,44 @@
---
id: "e5db2ff6-64c6-4aaa-a070-67f6904bd7eb"
number: 115
title: "Rendre visibles les skills IdeA assignés dans le contexte effectif de chaque agent"
status: "closed"
priority: "high"
sprint: null
links: []
agentRefs: []
attachments: []
createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
updatedBy: {"kind":"agent","agent_id":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"}
createdAt: 1785497413891
updatedAt: 1785499018589
version: 3
---
Constat: les agents n'utilisent pas les skills IdeA parce qu'ils n'ont pas connaissance, au runtime, de la liste des skills qu'IdeA leur met à disposition.
Objectif:
Faire en sorte que, quel que soit l'agent/profil, la liste des skills IdeA assignés soit correctement visible et exploitable par le modèle.
Attendu produit/architecture:
- La liste des skills assignés doit être traitée comme un artefact d'orchestration/capability snapshot, pas comme du texte documentaire passif.
- Source de vérité unique côté orchestrateur: catalogue réel des skills + règles d'assignation par agent.
- Injection systématique de cette liste dans le contexte effectif/prompt livré au modèle:
- au lancement
- à la reprise
- au handoff/changement de profil
- idéalement à chaque reconstruction de contexte/tour
- Format injecté court, stable, structuré et provider-agnostic, avec version de snapshot/catalogue.
- Règles injectées explicitement: utiliser un skill listé quand la demande y correspond, lire son détail via idea_skill_read(name=...).
- Fallback runtime si la liste change: soit mécanisme de refresh orchestrateur, soit endpoint/outillage canonique de relecture de la liste assignée.
Invariants à garantir:
- ne jamais annoncer un skill non réellement accessible
- ne jamais omettre un skill réellement assigné
- aucun agent ne commence un tour sans snapshot de skills cohérent avec l'état orchestrateur
- comportement homogène quel que soit le provider/profil
- snapshot versionné et traçable
Critères de validation:
- pour un agent ayant des skills assignés, la liste apparaît bien dans le contexte effectif vu par le modèle
- l'agent peut citer/consommer un skill assigné sans connaissance préalable externe
- un changement d'assignation est reflété sans dérive durable entre orchestrateur et agent

View File

@ -0,0 +1,6 @@
---
issueRef: "#116"
version: 2
updatedBy: {"kind":"agent","agent_id":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"}
updatedAt: 1785500328024
---

View File

@ -0,0 +1,39 @@
---
id: "0a38f0bc-e4c0-4e31-b682-738367463989"
number: 116
title: "Installer hello-plugin provoque un écran noir / crash apparent d'IdeA"
status: "closed"
priority: "critical"
sprint: null
links: []
agentRefs: []
attachments: []
createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
updatedBy: {"kind":"agent","agent_id":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"}
createdAt: 1785499247761
updatedAt: 1785500328024
version: 2
---
Constat utilisateur au 2026-07-31 : lors de l'installation du plugin de démonstration `hello-plugin`, IdeA affiche encore un écran noir, ce qui laisse supposer un crash du runtime/fenêtre.
Contexte utile déjà observé :
- des correctifs précédents existent autour de `hello-plugin` et du runtime plugin, notamment :
- `fe5fe7c` : `fix(hello-plugin): prévient le crash de l'asset protocol dans le runtime Tauri`
- `aa85037` / `c100a03` : isolation des contributions plugin en erreur + durcissement menus
- `2c3a46e` / `6270f98` : corrections manifeste/contexte hello-plugin
- malgré cela, l'installation du plugin déclenche encore un écran noir côté utilisateur.
Objectif :
Identifier la cause racine exacte du black screen au moment de l'installation/chargement de `hello-plugin`, corriger le défaut, et garantir qu'un plugin défectueux ou mal chargé ne puisse plus faire tomber la fenêtre principale d'IdeA.
Attendu :
- reproduire le problème sur le flux réel d'installation du plugin
- localiser la couche fautive (installation, validation, asset protocol, chargement frontend, runtime contributions, rendu UI, Tauri)
- corriger la cause racine
- ajouter des tests de non-régression sur le chemin réel concerné
- si un plugin reste invalide/non chargeable, l'UI doit rester vivante avec un état d'erreur explicite, pas un écran noir
Critères de validation :
- installation réelle de `hello-plugin` sans écran noir ni crash apparent
- IdeA reste interactive même si le plugin échoue à se charger
- tests pertinents verts avec preuve réelle

View File

@ -0,0 +1,6 @@
---
issueRef: "#117"
version: 7
updatedBy: {"kind":"agent","agent_id":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"}
updatedAt: 1785503128343
---

View File

@ -0,0 +1,51 @@
---
id: "66e80f94-780b-4856-806d-ba4b96673630"
number: 117
title: "Garantir la synchronie métier de idea_ask_agent malgré les background tasks"
status: "closed"
priority: "high"
sprint: null
links: []
agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
attachments: []
createdBy: {"kind":"user"}
updatedBy: {"kind":"agent","agent_id":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"}
createdAt: 1785500280516
updatedAt: 1785503128343
version: 7
---
Constat : quand un agent `A` délègue une demande à un agent `B` via `idea_ask_agent`, `B` peut lancer une background task puis terminer son tour avant que cette tâche ne finisse. Dans ce cas, `A` peut recevoir une pseudo-réponse terminale trop tôt, alors que le travail réel n'est pas terminé.
Décision produit validée : `idea_ask_agent` doit rester synchrone d'un point de vue métier.
Cela implique :
- `A` ne doit jamais recevoir comme réponse métier finale un simple "task lancée" si le résultat utile dépend encore d'une background task.
- si `B` a besoin d'une background task pour produire sa réponse, la délégation `A -> B` reste ouverte.
- la background task est une étape interne du traitement de `B`, pas une réponse à `A`.
- à la fin de la task, IdeA réveille `B`, puis `B` rend la vraie réponse finale.
- `A` reste en attente du rendez-vous logique, même si techniquement le tour initial de `B` s'est terminé.
Objectif :
Faire en sorte qu'une background task lancée pendant un `idea_ask_agent` soit corrélée au rendez-vous inter-agent en cours, et que ce rendez-vous reste ouvert jusqu'à la réponse finale métier de `B`.
Invariants à garantir :
- `idea_ask_agent` ne se termine jamais par "task lancée" si le résultat utile dépend encore d'une background task.
- toute background task lancée pendant une délégation porte la corrélation du rendez-vous source.
- la complétion de task réveille `B`, pas `A` directement.
- `B` transforme ensuite le résultat en vraie réponse finale à `A`.
- la réponse capturée pour `A` n'est émise qu'après clôture logique du travail.
- reboot, cancel, timeout et échec de task ne doivent pas casser cette corrélation.
Découpage attendu :
1. Étendre le modèle de corrélation pour rattacher une background task à un rendez-vous délégué.
2. Introduire un état explicite de rendez-vous du type `WaitingOnBackgroundTask` ou équivalent.
3. Empêcher la clôture terminale d'un `idea_ask_agent` tant qu'une task corrélée est encore ouverte.
4. À la complétion, réveiller `B`, injecter le résultat dans son inbox, puis laisser `B` répondre à `A`.
5. Ajouter les tests de reprise après reboot, timeout, cancel et double complétion.
Critères de validation :
- `A` délègue à `B`, `B` lance une task longue, `A` n'obtient pas de faux terminal.
- à la fin de la task, `B` est réveillé et répond finalement à `A`.
- après redémarrage, la réponse finale revient encore à `A`.
- échec ou annulation de task produisent une réponse terminale cohérente côté `A`.
- aucune complétion ne reste orpheline hors du rendez-vous initial.

View File

@ -0,0 +1,6 @@
---
issueRef: "#119"
version: 1
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
updatedAt: 1785534242629
---

134
.ideai/tickets/119/issue.md Normal file
View File

@ -0,0 +1,134 @@
---
id: "b76431d7-f3a3-438f-ae3f-5648f5eda8ce"
number: 119
title: "Refondre le système de skills IdeA en capacités agent découvrables"
status: "open"
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: 1785534242629
updatedAt: 1785534242629
version: 1
---
## Constat
Le système actuel de skills IdeA est techniquement fonctionnel, mais conceptuellement centré sur l'injection de contenu plutôt que sur l'exposition de capacités agent.
État actuel confirmé dans le code :
- `Skill` + `SkillRef` avec deux scopes `global` / `project`.
- assignation des skills sur les agents via le manifeste.
- résolution au lancement, puis composition du contexte effectif.
- en mode MCP : bloc `# Skills disponibles` + lazy-load via `idea_skill_read(name)`.
- en mode non-MCP : dump complet du corps des skills dans le contexte.
- `idea_list_agents` retourne la forme `Agent` du manifeste, donc seulement des `SkillRef` bruts (`skillId` + `scope`), pas un inventaire de capacités utile à un agent ou à Main.
Le défaut de fond est que le catalogue de skills n'existe pas comme objet métier interrogeable. Il n'existe qu'au moment du rendu markdown dans `compose_convention_file`. Le système se comporte donc comme un mécanisme d'injection de documentation, puis simule partiellement une surface de capacités en mode MCP.
## Problèmes à résoudre
1. Les skills assignés ne sont pas modélisés comme un inventaire de capacités agent de premier ordre.
2. `idea_list_agents` ne permet pas de savoir ce que les autres agents savent faire, seulement quels `SkillRef` opaques leur sont assignés.
3. L'asymétrie MCP / non-MCP est un patch : mode MCP = affordances bornées, mode non-MCP = dump lourd.
4. Le système ne distingue pas explicitement un skill procédural (`workflow`) d'un skill de référence (`reference`).
5. Le modèle actuel n'est pas pleinement aligné avec la frontière produit déjà actée : surface AGENT bornée/distillée/pointeur ; surface HUMAINE riche.
## Cible produit / architecture
Faire évoluer les skills IdeA d'un modèle "contenu injecté" vers un modèle "capacités agent assignées et découvrables".
### Décisions cibles
- Garder :
- l'entité `Skill`.
- les scopes `global` / `project`.
- `SkillRef` dans le manifeste agent.
- `idea_skill_read(name)` comme primitive de lazy-load autorisée uniquement sur les skills assignés au requester.
- Ajouter :
- une nature explicite de skill, par exemple `SkillKind` avec au minimum :
- `Workflow` : procédure exécutable à la demande.
- `Reference` : savoir consultable, plus proche d'un contexte sélectif.
- Extraire un use case applicatif réutilisable, type :
- `ResolveAgentCapabilities(agent) -> [{ name, description, kind }]`
Ce use case devient la source de vérité commune pour :
- le bloc `# Skills disponibles` injecté dans le contexte agent.
- l'exposition des capacités d'un agent dans les surfaces de découverte.
### Arbitrages
- Ne pas créer de `idea_list_skills` global.
- Les skills ne sont pas des tools MCP uniformes de session.
- Ce sont des capacités portées par un agent.
- La bonne surface de découverte inter-agent est donc `idea_list_agents` enrichi, pas un catalogue global détaché des porteurs.
- Enrichir `idea_list_agents` avec un champ additif du type :
- `capabilities: [{ name, description, kind }]`
- Supprimer à terme le dump complet des corps de skills en mode non-MCP.
- Le remplacer par une surface bornée et homogène avec le mode MCP : catalogue compact + lecture à la demande via la surface adaptée au runtime.
- Distinguer la politique d'injection selon le type :
- `Workflow` : jamais injecté en corps complet par défaut.
- `Reference` : peut éventuellement être injecté de façon compacte selon des règles bornées (optionnel, à arbitrer plus tard).
## Frontières avec les autres surfaces IdeA
- Tools MCP :
- les skills ne deviennent pas des tools MCP.
- `idea_skill_read` reste un pont vers les skills, pas une matérialisation des skills comme tools.
- Contexte projet :
- le contexte reste global au projet et commun.
- un skill reste assignable sélectivement agent par agent.
- Mémoire durable :
- la mémoire reste un savoir stabilisé écrit dynamiquement.
- un skill reste une capacité/version de workflow éditée explicitement.
- Live-state :
- aucun recouvrement fonctionnel ; pas de mélange.
- Templates :
- à envisager plus tard : un template pourrait référencer des skills à assigner par défaut.
- en revanche, un template ne doit pas dupliquer le corps des skills.
- Plugins :
- hors périmètre ; ne pas confondre extension IDE humaine et capacité agent.
## Plan de migration incrémental
1. **Domaine**
- ajouter `SkillKind` sur `Skill` avec rétrocompatibilité (`default`).
2. **Application**
- extraire un use case dédié de résolution des capacités agent à partir des `SkillRef` assignés.
3. **Surfaces agent / orchestration**
- faire reposer `# Skills disponibles` sur ce use case au lieu de recalculer localement pendant le rendu markdown.
4. **Découverte inter-agent**
- enrichir `idea_list_agents` avec les capacités résolues de chaque agent, en gardant les `skills` bruts si nécessaire pour compatibilité.
5. **Unification MCP / non-MCP**
- supprimer le dump intégral non-MCP et le remplacer par une surface bornée cohérente avec le modèle capability-first.
6. **Optionnel ensuite**
- politique fine d'injection compacte pour certains skills `Reference` courts.
## Critères de succès
- Un agent neuf connaît immédiatement ses skills assignés sous forme d'affordances bornées, sans dépendre d'un dump lourd.
- Un agent ou Main peut découvrir les capacités utiles d'un autre agent sans manipuler des `SkillRef` opaques.
- Le système reste cohérent avec la séparation IdeA : surface agent bornée, surface humaine riche.
- Le modèle fonctionne proprement en MCP et hors MCP, sans dégradation conceptuelle majeure.
- `idea_skill_read` reste la primitive de lecture détaillée et d'autorisation.
## Notes
Ce ticket est un ticket de refonte/cadrage cible. Il ne demande pas de refaire le stockage ni de supprimer `idea_skill_read`. La refonte porte sur le modèle de capacité agent, la composition de contexte et les surfaces de découverte.

View File

@ -0,0 +1,6 @@
---
issueRef: "#120"
version: 1
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
updatedAt: 1785534496259
---

View File

@ -0,0 +1,34 @@
---
id: "f4218553-680a-4fbb-9514-a96eab79b8d8"
number: 120
title: "Réinvestiguer linstallation de hello-plugin: écran noir / perte daffichage IdeA"
status: "open"
priority: "critical"
sprint: null
links: [{"target":"#116","kind":"relatesTo"}]
agentRefs: []
attachments: []
createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
createdAt: 1785534496259
updatedAt: 1785534496259
version: 1
---
## Constat utilisateur
Au 2026-07-31, linstallation de `hello-plugin` fait encore perdre tout laffichage dIdeA (écran noir / UI vide), malgré un précédent correctif supposé sur `#116`.
## Objectif
Reprendre le sujet proprement avec un ticket neuf de réinvestigation et de durcissement:
- recréer un plugin de test minimal `hello-plugin` depuis zéro pour repartir dun cas maîtrisé ;
- renforcer les tests e2e autour du cycle dinstallation plugin ;
- identifier précisément la cause réelle de la perte daffichage ;
- corriger le ou les défauts (backend, frontend, runtime, permissions, flux dinstallation, etc.) ;
- valider la non-régression sur le cas `hello-plugin`.
## Notes de cadrage
- Le ticket nassume pas que la cause soit dans le plugin lui-même ; la reconstruction du plugin sert de témoin minimal reproductible.
- Le ticket doit sappuyer sur le précédent `#116` mais repart dun constat live utilisateur indiquant que le système plugin reste non fiable.
- La sortie attendue inclut des tests e2e réellement exécutés et un rebuild AppImage pour validation dans le binaire utilisé par IdeA.

View File

@ -0,0 +1,6 @@
---
issueRef: "#121"
version: 2
updatedBy: {"kind":"agent","agent_id":"dce19c75-9669-4e45-b8de-9950025157da"}
updatedAt: 1785534534027
---

View File

@ -0,0 +1,16 @@
---
id: "07d83a8e-63cd-4f72-b056-aaf792d517fb"
number: 121
title: "__probe__"
status: "closed"
priority: "medium"
sprint: null
links: []
agentRefs: []
attachments: []
createdBy: {"kind":"agent","agent_id":"dce19c75-9669-4e45-b8de-9950025157da"}
updatedBy: {"kind":"agent","agent_id":"dce19c75-9669-4e45-b8de-9950025157da"}
createdAt: 1785534526705
updatedAt: 1785534534027
version: 2
---

View File

@ -1,3 +1,3 @@
{
"nextNumber": 115
"nextNumber": 122
}

View File

@ -1450,19 +1450,6 @@
},
"updatedAt": 1785328001167
},
{
"issueRef": "#111",
"path": "111",
"title": "Gestion tmp des outils idea",
"status": "open",
"priority": "medium",
"sprint": null,
"assignedAgentIds": [],
"createdBy": {
"kind": "user"
},
"updatedAt": 1785390694060
},
{
"issueRef": "#112",
"path": "112",
@ -1497,7 +1484,7 @@
"issueRef": "#114",
"path": "114",
"title": "[UI] un iformiser les droplist",
"status": "open",
"status": "closed",
"priority": "medium",
"sprint": "5afd6780-0f76-40d7-a10f-32ee52469d74",
"assignedAgentIds": [
@ -1506,7 +1493,92 @@
"createdBy": {
"kind": "user"
},
"updatedAt": 1785395923498
"updatedAt": 1785509526119
},
{
"issueRef": "#115",
"path": "115",
"title": "Rendre visibles les skills IdeA assignés dans le contexte effectif de chaque agent",
"status": "closed",
"priority": "high",
"sprint": null,
"assignedAgentIds": [],
"createdBy": {
"kind": "agent",
"agent_id": "a6ced819-b893-4213-b003-9e9dc79b9641"
},
"updatedAt": 1785499018589
},
{
"issueRef": "#116",
"path": "116",
"title": "Installer hello-plugin provoque un écran noir / crash apparent d'IdeA",
"status": "closed",
"priority": "critical",
"sprint": null,
"assignedAgentIds": [],
"createdBy": {
"kind": "agent",
"agent_id": "a6ced819-b893-4213-b003-9e9dc79b9641"
},
"updatedAt": 1785500328024
},
{
"issueRef": "#117",
"path": "117",
"title": "Garantir la synchronie métier de idea_ask_agent malgré les background tasks",
"status": "closed",
"priority": "high",
"sprint": null,
"assignedAgentIds": [
"a6ced819-b893-4213-b003-9e9dc79b9641"
],
"createdBy": {
"kind": "user"
},
"updatedAt": 1785503128343
},
{
"issueRef": "#119",
"path": "119",
"title": "Refondre le système de skills IdeA en capacités agent découvrables",
"status": "open",
"priority": "high",
"sprint": null,
"assignedAgentIds": [],
"createdBy": {
"kind": "agent",
"agent_id": "a6ced819-b893-4213-b003-9e9dc79b9641"
},
"updatedAt": 1785534242629
},
{
"issueRef": "#120",
"path": "120",
"title": "Réinvestiguer linstallation de hello-plugin: écran noir / perte daffichage IdeA",
"status": "open",
"priority": "critical",
"sprint": null,
"assignedAgentIds": [],
"createdBy": {
"kind": "agent",
"agent_id": "a6ced819-b893-4213-b003-9e9dc79b9641"
},
"updatedAt": 1785534496259
},
{
"issueRef": "#121",
"path": "121",
"title": "__probe__",
"status": "closed",
"priority": "medium",
"sprint": null,
"assignedAgentIds": [],
"createdBy": {
"kind": "agent",
"agent_id": "dce19c75-9669-4e45-b8de-9950025157da"
},
"updatedAt": 1785534534027
}
]
}