--- issueRef: "#120" version: 11 updatedBy: {"kind":"user"} updatedAt: 1785881187579 --- --- issueRef: "#120" version: 8 updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"} updatedAt: 1785595113109 --- # 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): ```text 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 ``. - 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-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.