IdeA/.ideai/tickets/120/carnet.md

issueRef, version, updatedBy, updatedAt

issueRef	version	updatedBy	updatedAt
#120	11	kind user	1785881187579

Carnet de suivi — hello-plugin

Etat courant

• Ticket canonique: #120
• Ticket parent historique: #43
• Date de rechute confirmee: 2026-08-01
• Statut: investigation relancee sur rechute reelle post-rebuild SDK
• Severite: critique (l'UI d'IdeA tombe sur une erreur d'affichage lors de l'installation/chargement de hello-plugin)

Constat central au 2026-08-01

Le probleme persiste meme apres reconstruction de hello-plugin comme plugin d'exemple 100% SDK.

Implication forte:

• la cause racine est probablement dans le systeme plugin / runtime frontend / chargement UI / integration layout-menu, et non dans l'ancien exemple hello-plugin uniquement.

Trace utilisateur fournie le 2026-08-01

Message visible:

• IdeA a rencontre une erreur d'affichage.
• L'application reste ouverte. Rechargez la fenetre apres avoir copie le diagnostic si le probleme doit etre investigue.

Stack affichee (trace la plus recente):

ST@tauri://localhost/assets/index-DxqF_K_z.js:88:33125
wT@tauri://localhost/assets/index-DxqF_K_z.js:88:32065
om@tauri://localhost/assets/index-DxqF_K_z.js:38:17019
oh@tauri://localhost/assets/index-DxqF_K_z.js:40:3141
Fb@tauri://localhost/assets/index-DxqF_K_z.js:40:39779
SC@tauri://localhost/assets/index-DxqF_K_z.js:40:39707
ic@tauri://localhost/assets/index-DxqF_K_z.js:40:39559
yh@tauri://localhost/assets/index-DxqF_K_z.js:40:35923
Bb@tauri://localhost/assets/index-DxqF_K_z.js:40:34872
E@tauri://localhost/assets/index-DxqF_K_z.js:25:1541
L@tauri://localhost/assets/index-DxqF_K_z.js:25:1903

wT@tauri://localhost/assets/index-DxqF_K_z.js:88:28284
div
div
div
MD@tauri://localhost/assets/index-DxqF_K_z.js:94:63541
main
div
div
G4@tauri://localhost/assets/index-DxqF_K_z.js:129:18726
div
div
yT@tauri://localhost/assets/index-DxqF_K_z.js:88:24863
BP@tauri://localhost/assets/index-DxqF_K_z.js:88:1862
ez@tauri://localhost/assets/index-DxqF_K_z.js:129:31967
mP@tauri://localhost/assets/index-DxqF_K_z.js:82:27658
Iz@tauri://localhost/assets/index-DxqF_K_z.js:129:83720

Faits etablis avant cette rechute

• Un rebuild SDK de hello-plugin a ete realise pour produire un plugin d'exemple minimal mais fonctionnel.
• Des verifications de build, packaging et tests locaux ont ete annoncees vertes par DevFrontend.
• QA avait pu valider partiellement:
  • l'artefact SDK se reconstruit
  • le plugin s'installe cote runtime/backend
  • IdeA charge reellement le bundle plugin via idea-plugin://.../dist/index.js
• QA n'avait pas pu valider de bout en bout la surface UI visible (menu Hello Plugin, entree hello-plugin, rendu hello-world) faute d'une session UI observable sans ambiguite.

Reinterpretation apres rechute utilisateur

• L'absence de validation UI de bout en bout n'etait pas un detail: la rechute utilisateur montre que le crash survient bien dans le flux reel d'affichage, malgre un plugin reconstruit proprement.
• Le signal pointe desormais plus fortement vers un probleme dans la consommation frontend des contributions plugin que vers le contenu fonctionnel du plugin lui-meme.

Cadrage UX du 2026-08-01

• Une contribution plugin invalide ou qui plante ne doit jamais faire tomber l'app entiere.
• Le fallback attendu est local a la surface plugin en faute:
  • menu plugin en erreur -> menus natifs seuls
  • layout plugin en erreur -> fallback local de layout indisponible
• INTERFACE INTERROMPUE doit rester reserve aux crashs shell irrecoverables.
• A terme, l'etat d'erreur plugin devrait rester visible dans la gestion des plugins plutot qu'etre seulement silencieux.

Requalification Architect du 2026-08-01

• Fait cle: le meme hash de crash apparait avec deux plugins differents:
  • ancien hello-plugin minimal (menu + item, sans layout utile)
  • nouveau hello-plugin reconstruit via SDK (menu + item + layout)
• Denominateur commun probable: la contribution de menu, pas le layout.
• Zone la plus suspecte identifiee: ProjectsView.tsx sur l'injection de pluginMenus dans <MenuBar>.
• Point precis: le rendu des menus plugin est consomme dans l'app-shell sans isolation locale equivalente a celle deja ajoutee pour PluginLayoutCellView.
• Hypothese prioritaire: une entree de menu plugin ou son rendu dans MenuBar leve une erreur qui remonte jusqu'a RootErrorBoundary, produisant INTERFACE INTERROMPUE.
• Strate touchee: frontend prioritaire, pas de nouveau chantier backend requis pour cette cause racine.

Verification DevFrontend du 2026-08-01

• Branche verifiee: feature/ticket120-plugin-menu-crash-isolation
• HEAD verifie: 5a30ec8
• Verdict DevFrontend: le correctif existant couvre deja la rechute prioritaire sur le chemin ProjectsView -> usePluginMenus -> MenuBar.
• Aucun complement de code ajoute a ce stade.
• Verifications executees:
  • cd frontend && npx vitest run src/features/plugins/usePluginMenus.test.tsx src/plugins/runtime/loader.test.ts src/features/plugins/menus.test.ts : OK (22 tests)
  • cd frontend && npx vitest run : OK (114 fichiers, 1046 tests)

Correctif systeme plugin/UI deja porte par la branche

Cause probable retenue

Deux plugins differents declenchent le meme crash minifie apres installation. Le denominateur commun le plus probable est le chemin ProjectsView -> usePluginMenus -> MenuBar.

Correctif applique

• usePluginMenus isole defensivement la resolution/conversion des contributions plugin.
• Si la resolution de menus ou d'items plugin throw, le hook renvoie [] pour la surface plugin concernee au lieu de propager l'erreur.
• ProjectsView separe les menus natifs des menus enrichis par plugin.
• ProjectsView rend MenuBar derriere une error boundary locale: si le rendu enrichi plante, fallback immediat sur les menus natifs seuls.
• Logs ajoutes:
  • [plugins] menu contribution rejected avec le contexte utile quand disponible
  • [plugins] menu render failed; using native menus only

Fichiers touches

• frontend/src/features/plugins/usePluginMenus.ts
• frontend/src/features/plugins/usePluginMenus.test.tsx
• frontend/src/features/projects/ProjectsView.tsx

Validation QA du 2026-08-01

• Branche validee: feature/ticket120-plugin-menu-crash-isolation
• HEAD valide: 5a30ec8b9c4758602cc96e72ffd69e415422cd85
• Verdict QA courant: bug INTERFACE INTERROMPUE non reproduit par les validations reelles executees ici.

Commandes executees

• git -C /home/anthony/Documents/Projects/IdeA rev-parse HEAD
• npm --prefix /home/anthony/Documents/Projects/IdeA/sdk/IdeaSDK run package:hello-plugin
• cd /home/anthony/Documents/Projects/IdeA/frontend && npx vitest run src/features/plugins/menus.test.ts src/features/plugins/usePluginMenus.test.tsx src/features/plugins/plugins.test.tsx src/plugins/runtime/loader.test.ts
• cargo test -p infrastructure --test plugin_install_load -- --nocapture
• cargo test -p infrastructure extracts_archive_without_path_escape -- --nocapture
• cd /home/anthony/Documents/Projects/IdeA/frontend && npm run test:bundle-transport
• cd /home/anthony/Documents/Projects/IdeA/crates/app-tauri && NO_STRIP=true ../../frontend/node_modules/.bin/tauri build --bundles appimage

Resultats utiles

• archive SDK regeneree: sdk/IdeaSDK/examples/hello-plugin/build/hello-plugin-0.1.0.zip
• tests frontend cibles: OK (4 fichiers, 29 tests)
• tests backend d'installation/chargement plugin: OK (3 tests)
• AppImage rebuild: target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage

Limite de preuve restante

• Pas de harness e2e UI automatise ici pour cliquer le parcours Tauri/AppImage "Installer depuis une archive..." de bout en bout.
• La validation est donc reelle sur archive SDK, backend d'installation, non-regression frontend, et artefact packagé reconstruit, mais pas sur un clic UI automatise observable.

Requalification Architect du 2026-08-01 (rechute post-rebuild)

Fait determinant trouve par inspection directe des artefacts

Deux binaires AppImage distincts coexistent sur la machine, avec un ecart temporel et de contenu net:

Fichier	mtime	sha256 (8 premiers car.)
/home/anthony/Documents/IdeA_0.3.0_amd64.AppImage (celui qu'IdeA fait tourner — cf. memoire mcp-bridge-and-delegation-runtime-notes)	2026-07-24 15:09	61d499f2
target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage (rebuild QA du jour)	2026-08-01 16:37	9ad50c21

Le commit du correctif (5a30ec8, isolation usePluginMenus/ProjectsView) date du 2026-08-01 16:23:56, soit apres le mtime du binaire ~/Documents. Le binaire que l'utilisateur execute au quotidien (~/Documents/IdeA_0.3.0_amd64.AppImage) est donc anterieur de plusieurs jours au correctif et ne peut structurellement pas le contenir.

Requalification de cause racine

• La rechute rapportee le 2026-08-01 par l'utilisateur est tres vraisemblablement un artefact de deploiement, pas une regression de code: le rebuild QA a produit un binaire correct dans target/release/bundle/appimage/, mais ce binaire n'a jamais remplace celui reellement lance par l'utilisateur (~/Documents/IdeA_0.3.0_amd64.AppImage).
• C'est exactement le piege deja documente en memoire projet (mcp-bridge-and-delegation-runtime-notes, section « Le binaire qui tourne = AppImage installee, pas les sources ») applique cette fois au correctif plugin plutot qu'au pont MCP.
• Le carnet QA ci-dessus ne mentionne a aucun moment le remplacement du binaire ~/Documents ni le redemarrage d'IdeA sur ce binaire remplace — seule la production de l'artefact dans target/release/bundle/ est tracee.

Borne de correction attendue

• Aucun nouveau code frontend ou backend n'est requis a ce stade. Le correctif 5a30ec8 (isolation menus plugin) est deja en place et deja valide par tests reels (114 fichiers / 1046 tests vitest, tests backend d'installation/chargement).
• Action requise: deploiement, pas developpement — remplacer ~/Documents/IdeA_0.3.0_amd64.AppImage par target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage (backup de l'ancien conseille, cf. convention memoire *.old-<raison>fix), relancer IdeA depuis ce binaire, puis reproduire exactement le parcours Parametres > Plugins > Installer depuis une archive > hello-plugin.
• Si la rechute persiste APRES ce remplacement effectif et un redemarrage complet d'IdeA, alors l'hypothese frontend doit etre rouverte avec un perimetre elargi au-dela de ProjectsView -> usePluginMenus -> MenuBar, en verifiant en priorite (deja inspectes le 2026-08-01, RAS a la lecture statique mais non exerces en e2e reel):
  • frontend/src/features/plugins/PluginsPanel.tsx (flux startInstallFromArchive / reviewArchive / dialog de confirmation) — surface active au moment precis du clic « Installer »
  • frontend/src/features/plugins/PluginConfirmDialog.tsx
  • frontend/src/features/plugins/PluginLayoutCellView.tsx (isolation deja posee en amont de ce ticket, a re-verifier qu'elle couvre bien le layout du hello-plugin reconstruit)
  • la place de RootErrorBoundary par rapport a ces surfaces, pour confirmer qu'aucun chemin ne la contourne

Prochaine etape (remplace la precedente)

• Ne pas rouvrir de chantier de code avant d'avoir confirme que l'utilisateur reproduit sur le binaire effectivement a jour.
• Remplacement de binaire + retest = action Git/deploiement, a executer avant toute nouvelle investigation frontend.

Requalification Architect du 2026-08-01 (nouveau symptome CORS apres installation)

Nouveau fait utilisateur

Le symptome visible n'est plus seulement un ecran noir: dans la vue Plugins, IdeA affiche apres installation de hello-plugin un bandeau explicite:

• Certains plugins installes n'ont pas pu etre charges.
• com.example.hello-plugin : Cross-origin script load denied by Cross-Origin Resource Sharing policy.

Cette observation invalide la piste LayoutTabs -> PluginLayoutSelectorSection comme cause racine de ce symptome precis. Le durcissement frontend precedent reste utile: il a empeche le black screen et laisse remonter l'erreur exploitable.

Cause racine retenue

• Le protocole custom idea-plugin:// repondait sans headers CORS dans crates/app-tauri/src/plugins.rs (plugin_asset_response).
• Le frontend charge le bundle plugin via import() dynamique depuis frontend/src/plugins/runtime/loader.ts; ce chargement est un fetch CORS.
• L'origine du document (tauri://localhost / http://tauri.localhost en prod, http://localhost:5173 en dev) est distincte de idea-plugin://....
• Faute de Access-Control-Allow-Origin, WebKitGTK bloque le module avec exactement le message observe.

Couche proprietaire et perimetre de correction

• Couche proprietaire: backend/infrastructure app-tauri, pas frontend produit, pas packaging plugin.
• Correctif attendu:
  • ajouter Access-Control-Allow-Origin sur les reponses du protocole plugin
  • ajouter Access-Control-Allow-Methods: GET
  • conserver intact le confinement asset_allowed
  • ajouter un test backend verrouillant ces headers sur plugin_asset_response

Livraison DevBackend du 2026-08-01

• Branche de travail dediee: feature/ticket120-plugin-asset-cors-headers
• Correctif implemente dans crates/app-tauri/src/plugins.rs
• Headers ajoutes sur les reponses du protocole idea-plugin://:
  • Access-Control-Allow-Origin: *
  • Access-Control-Allow-Methods: GET
• Factorisation via un builder de reponse commun aux chemins succes/erreur du protocole
• Test ajoute: plugin_asset_response_includes_cors_headers_for_dynamic_import

Commandes executees par DevBackend

• cargo fmt -p app-tauri : OK
• cargo test -p app-tauri plugin_asset_response_includes_cors_headers_for_dynamic_import : OK
• cargo test -p app-tauri plugins::tests : OK
• cargo test -p app-tauri : OK (242 passed, 0 failed, 5 ignored)

Validation QA du 2026-08-01 (fix CORS)

Verdict

• PASS avec reserve explicite.

Validation reelle obtenue

• cargo test -p app-tauri plugin_asset_response_includes_cors_headers_for_dynamic_import -- --nocapture : OK
• cargo test -p app-tauri : OK
• cargo test -p infrastructure --test plugin_install_load installs_sdk_hello_plugin_and_loads_runtime_catalog -- --nocapture : OK
• cargo test -p infrastructure --test plugin_install_load installs_reference_fixture_and_loads_runtime_catalog -- --nocapture : OK
• npm --prefix /home/anthony/Documents/Projects/IdeA/sdk/IdeaSDK run package:hello-plugin : OK
• cd /home/anthony/Documents/Projects/IdeA/frontend && npx vitest run src/plugins/runtime/loader.test.ts src/features/plugins/plugins.test.tsx src/features/plugins/menus.test.ts : OK (27 tests)

Reserve QA restante

• Pas de preuve visuelle AppImage/UI de bout en bout dans cet environnement.
• Tentative de build AppImage realisee, mais l'artefact final n'etait pas disponible ensuite dans target/release/bundle/appimage/.
• Tentative d'execution d'une AppImage existante bloquee par l'environnement (No suitable fusermount binary found on the $PATH).
• Risque residuel exact: le fix est prouve au niveau handler backend, catalogue runtime et chargeur frontend, mais pas sur l'enchainement visuel complet archive installee -> redemarrage UI reel -> absence du bandeau CORS.

Decision Git du 2026-08-01

• Commit local realise sur la branche dediee: fbe69de
• Merge local --no-ff dans develop: fd2ab4a
• Motivation: QA a rendu un verdict PASS; la reserve porte sur une limite d'environnement de preuve AppImage/FUSE, pas sur un test rouge.
• La branche feature/ticket120-plugin-asset-cors-headers a ete supprimee apres merge.

Etat reel a la fin de cette relance

• Le correctif CORS est livre dans develop.
• Le ticket reste a considerer ouvert fonctionnellement tant qu'une validation visuelle reelle sur AppImage/redemarrage n'a pas confirme la disparition du bandeau Cross-origin script load denied by Cross-Origin Resource Sharing policy et l'activation effective des contributions hello-plugin.
• Prochaine preuve attendue hors environnement QA courant: lancer le binaire AppImage reellement utilise par l'utilisateur, installer l'archive hello-plugin, redemarrer IdeA, verifier visuellement l'absence du bandeau CORS et la presence des contributions plugin actives.