Les contributions runtime des plugins (menus, slash commands, layouts,
surfaces) ne sont exposées que dans les projets liés au plugin.
- Définition du lien: ProjectPluginSettingsStore par racine projet
(domaine) — une contribution runtime-active n'entre dans le catalogue
que si elle est explicitement activée pour le projet courant; hors
projet focalisé, catalogue vide
- Application: ListPluginRuntimeContributions.execute prend un
project_id optionnel, charge projet + settings et filtre le registre
par activation projet; tests fake store/settings (catalogue vide sans
projet, activation, layout, slash commands)
- Backend/app-tauri: plugin_list_runtime_contributions et slash
commands list/execute acceptent projectId optionnel (DTO camelCase,
défaut serde), BackendCore recâblé avec store_port et
project_plugin_settings_store; test DTO de scope optionnel
- Frontend: PluginGateway.listRuntimeContributions(projectId) (ports,
tauri, http/unsupported, mock alignés); PluginRuntimeProvider
re-scope le catalogue au changement de focus projet (vidage du
registre précédent, disposition des bundles, requêtes obsolètes
ignorées par projectId/révision); PluginLayoutCellView ignore les
références de layout devenues hors périmètre via onChooseAnotherLayout
et ne rend rien pendant le rechargement (aucune fuite inter-projets)
- Tests: plugin_install_load (infrastructure), dto slash commands,
plugin.test, PluginRuntimeProvider.test, PluginLayoutCellView.test
QA verte sur feature/321-plugin-contributions-linked-projects. Aucun push.
Permet à un plugin de contribuer des commandes slash adossées à une callback,
transitant par le registry/contrat unifié (#162) :
- sdk/IdeaSDK: manifeste contributes.slashCommands (déclaratif) — pointer bumpé.
- domain: source Plugin étendue + effet PluginCallback (la commande ne
s'exécute pas directement : elle renvoie une référence à la callback du plugin).
- application: registration des commandes plugin dans le registry + exécution
renvoyant l'effet PluginCallback ; métadonnées UI suffisantes pour l'autocomplete.
- backend + app-tauri: DTO + commandes Tauri listant/invoquant les commandes plugin.
- frontend (contrat): types adapters/domain/ports/mock pour pluginCallback et
l'invocation avec arguments.
L'exécution effective de la callback côté runtime UI est livrée par #166.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
État d'intégration confiné à la branche batch. Les tickets #119 (skills →
capacités agent découvrables), #122 (override permissions par défaut), #131
(effort par agent/presets) et #132 (outil MCP d'édition du contexte projet)
sont verts en périmètre. Le sprint plugins multi-fichiers ESM / persistance
plugin-owned (#135/#136/#139) est co-implémenté dans les MÊMES fichiers de
câblage (frontend/src/ports/index.ts, backend/src/lib.rs, domain/ports.rs,
backend/dto.rs), inséparable sans staging interactif (indisponible ici).
Commit unique volontaire : préserve l'état vert QA sans découpe hunk risquée.
NON mergé vers develop tant que #137 (QA e2e plugins) n'est pas vert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- plugin_install_load.rs: test uninstalls_then_reinstalls_sdk_hello_plugin_without_runtime_residue()
- application/src/plugin/mod.rs: refactor FakePackages pour supporter plusieurs staged packages et nettoyer les manifests sur uninstall
- Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Requalification Architect du 2026-08-01: le crash INTERFACE INTERROMPUE au
chargement d'un plugin (menu + item) remonte via ProjectsView -> usePluginMenus
-> MenuBar jusqu'à RootErrorBoundary, quel que soit le plugin (ancien ou
reconstruit via SDK).
- usePluginMenus isole la résolution/conversion des contributions plugin :
toute erreur retombe sur [] au lieu de propager.
- ProjectsView sépare les menus natifs des menus enrichis par plugin et rend
MenuBar derrière une error boundary locale (fallback menus natifs seuls).
- hello-plugin (SDK) et les tests d'installation associés durcis en cohérence.
Bookkeeping ticket #120 uniquement (issue.md, carnet.md) ; les fichiers
counter.json/index.json et le dossier tickets/122/ restent hors commit car
une collision de numérotation #122 existe entre cette base et
feature/ticket120-hello-plugin-install-path-audit (deux tickets différents
revendiquent #122) — à arbitrer avant de committer le bookkeeping global.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Un bundle_url invalide ou un plugin dont l'asset n'est pas réellement
servable passe désormais en état Invalid isolé au lieu de faire
échouer globalement la réconciliation MCP au démarrage — cause racine
de la perte d'affichage à l'installation de hello-plugin (#116/#120).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Ajoute block_on_protocol_future() pour éviter l'erreur 'Cannot start a runtime from within a runtime'
- Ajoute test unitaire pour vérifier la compatibilité avec le runtime Tauri
- Ajoute test d'intégration pour le hello-plugin du SDK
Le manifeste hello-plugin était généré par un SDK obsolète/désaligné avec le
schéma backend actuel (champ ideaPluginManifestVersion manquant, displayName,
trustLevel, shape de contributes), ce qui faisait échouer l'installation avec
« invalid input: missing field ideaPluginManifestVersion ».
- SDK (manifest.ts/js, index.ts) aligné sur le schéma backend courant.
- hello-plugin (exemple + fixture) régénéré avec le manifeste valide.
- Base de tests fonctionnels plugins : fixture réelle versionnée
(reference-minimal) + test d'installation/chargement bout en bout
(plugin_install_load.rs), pour couvrir install/load/catalog depuis un
dossier fixture réel.
Le sous-repo git imbriqué et vide (sdk/IdeaSDK/.git, 0 commit) a été
neutralisé pour que les sources du SDK soient suivies normalement dans ce
dépôt plutôt que comme gitlink vide.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
