IdeA/.ideai/tickets/149/carnet.md

issueRef, version, updatedBy, updatedAt

issueRef	version	updatedBy	updatedAt
#149	15	kind agent_id agent a6c6ea12-bfc6-4bdc-8031-324102dfa34d	1785937428431

Historique des tentatives

2026-08-05 — Reouverture utilisateur

• Symptome utilisateur revalide: la CLI custom s'ouvre environ une demi-seconde puis la cellule retombe directement vers Plain/TUI.
• Le ticket etait encore en QA alors que le comportement attendu n'est pas corrige en pratique.
• Constat de pilotage: le carnet etait vide, donc les tentatives precedentes n'etaient pas tracees ici.
• Action Main: reouverture du ticket et relance d'un cycle complet Architect -> Git -> DevFrontend -> QA.

Piste precedemment documentee dans la description

• Hypothese precedente: fallback premature dans frontend/src/features/layout/LayoutGrid.tsx pendant le chargement asynchrone initial du catalogue agent/profil, ecrasant cellMode="custom" restaure depuis le storage.
• Cette piste n'a pas suffi a eliminer le symptome utilisateur, donc elle doit etre revalidee ou completee avant nouvelle correction.

2026-08-05 — Recadrage Architecture (avant nouvelle implementation)

1) Decouverte critique : ecart de validation binaire — a verifier EN PREMIER

• L'AppImage installee (~/Documents/IdeA_0.3.0_amd64.AppImage) a ete buildee le 2026-08-03 09:39.
• Les 3 commits de correctif frontend sur ce ticket sont tous posterieurs :
  • 51bda204 "preserve custom CLI preference during catalog load"
  • 61055779 "retarde le fallback custom→TUI tant que le catalogue agents/profiles est stale" (2026-08-05 ~14:2x)
  • e9e4623e "stabilise le mode CLI custom contre le refetch stale agents/profiles" (2026-08-05 14:24:55)
  • merge 66b9c34b (2026-08-05 14:25:03)
• Le ticket a ete reouvert a 14:31:10, soit 6 minutes apres le merge — le retest utilisateur qui a motive la reouverture a tres probablement ete fait contre le binaire du 03/08, qui ne contient aucun des 3 correctifs.
• Rappel memoire projet (mcp-bridge-and-delegation-runtime-notes): piege recurrent dans ce projet — un correctif commite aux sources n'est actif dans l'app qu'apres rebuild + reinstall de l'AppImage + relance d'IdeA. Ne jamais interpreter un retest utilisateur comme invalidant une hypothese de fix sans confirmer que le binaire teste contient bien ce fix.
• Action requise avant tout nouveau code : rebuild AppImage depuis develop (contient deja les 3 correctifs), remplacer le binaire installe, relancer IdeA, refaire le repro utilisateur. Si le symptome disparait, le ticket se cloture sans ecrire une ligne de code supplementaire.

2) Perimetre confirme si le symptome persiste apres rebuild

• Le bug reste frontend-pur dans son mecanisme d'affichage : le point de bascule visuelle custom→TUI est entierement local a LeafView dans frontend/src/features/layout/LayoutGrid.tsx (ligne ~1291) : agentId && cellMode === "custom" && effectiveCustomCliAvailable && customCliAgent && customCliProfile — si une seule de ces conditions devient fausse, le rendu bascule silencieusement sur TerminalView (Plain/TUI) sans jamais toucher cellMode lui-meme dans les cas ou customCliAvailable retombe a faux transitoirement.
• Verification cote backend : reattach_agent_chat (crates/app-tauri/src/commands.rs:2659-2687) est concu pour etre idempotent en cas de reattach concurrent/duplique ("generation supersede, no double emission" — commentaire du code). Cette piste backend (un kill de session cote serveur sur double-attach) est donc ecartee ; aucune preuve de contrat backend fautif a ce jour.

3) Nouvelle piste non explorees par les 3 correctifs precedents

• Les 3 correctifs precedents ont tous patché la garde shouldFallbackCustomCliMode / l'effet de fallback dans LayoutGrid.tsx. Aucun n'a touche frontend/src/features/agents/CustomAgentChatView.tsx.
• Piste a instrumenter si le symptome persiste apres rebuild : l'effet openOrAttach de CustomAgentChatView.tsx (lignes ~221-266) depend de la prop sessionId. Or ce meme effet, via recoverStructuredSession, appelle onSessionIdRef.current(launched.sessionId) (ligne ~184) avant d'avoir fini son propre reattachStructuredSession — ce callback remonte par vm.setSession (LayoutGrid) et fait changer la prop sessionId elle-meme, ce qui redeclenche l'effet une seconde fois en parallele (double appel reattachStructuredSession sur la meme session). Le backend tolere ce doublon (cf §2) donc ce n'est probablement pas fatal en soi, mais c'est un feedback loop d'effet non intentionnel, jamais audite, et un candidat concret pour la 4e iteration si le probleme n'est pas qu'un binaire perime.

4) Perimetre minimal propose pour la prochaine correction (non-regressif)

1. Etape 0 (obligatoire, avant tout code) : rebuild AppImage depuis develop, relancer IdeA, refaire le repro utilisateur reel. Ne pas coder avant ce resultat.
2. Si le symptome persiste : instrumenter (log temporaire, retire avant merge) les transitions reelles de cellMode, customCliAvailable, effectiveCustomCliAvailable, trustedCustomCli (LayoutGrid) ET le cycle de vie de l'effet openOrAttach / des appels launchAgentChat/reattachAgentChat (CustomAgentChatView) sur un repro utilisateur reel, capture avant toute nouvelle modif.
3. Ne pas retoucher une 4e fois shouldFallbackCustomCliMode/l'effet de fallback de LayoutGrid.tsx sans preuve de trace nouvelle — 3 iterations dessus sans effet observable est en soi un signal que soit l'hypothese est fausse, soit la validation ne portait pas sur le bon binaire (cf §1).
4. Correctif candidat le plus probable si la piste §3 se confirme : stabiliser l'effet openOrAttach pour qu'il ne reagisse pas a son propre onSessionId (ex. distinguer une mise a jour "externe" de sessionId d'une mise a jour "auto-emise", via un ref plutot que la prop brute dans les deps).

5) A consigner pour eviter de repasser sur les fausses pistes

• Toujours verifier la date de build de l'AppImage installee vs. la date des commits de fix avant d'interpreter un retest utilisateur comme un echec du correctif.
• La piste "fallback premature pendant chargement catalogue" (LayoutGrid.tsx) a ete testee 3x (commits 51bda204, 61055779, e9e4623e) sans confirmation terrain valide (cf §1) — ne pas la considerer refutee tant que le rebuild+retest n'a pas ete fait proprement.
• reattach_agent_chat backend est idempotent par design (generation supersede) — ecarter la piste "double attach tue la session cote serveur" sauf nouvelle preuve.
• Piste ouverte et non testee : boucle d'effet sessionId dans CustomAgentChatView.tsx (cf §3) — a instrumenter avant de patcher.

2026-08-05 — Verification binaire / rebuild AppImage

• Decision Git: rester sur develop, aucune nouvelle branche tant qu'on est en simple verification binaire. develop contient deja le merge 66b9c34b et les 3 correctifs frontend lies au ticket.
• Build frontend execute avec succes: npm --prefix frontend run build.
• Bundle Tauri AppImage execute avec succes depuis crates/app-tauri/ via le workflow build-appimage: CARGO_HOME=/tmp/idea-cargo-home APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 ../../frontend/node_modules/.bin/tauri build --bundles appimage
• Artefact produit avec succes: /home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
• Verification des dates:
  • AppImage installee actuelle: 2026-08-03 09:39:38 +0200 — /home/anthony/Documents/IdeA_0.3.0_amd64.AppImage
  • AppImage rebuild ticket #149: 2026-08-05 14:40:14 +0200 — /home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
• Conclusion de cette tentative: le ticket n'est pas encore un echec de correctif code. Le repro utilisateur doit etre refait sur ce nouveau binaire, apres remplacement manuel de l'AppImage installee puis relance d'IdeA.
• Etape suivante obligatoire avant toute 4e modif frontend: remplacer l'AppImage installee par l'artefact rebuild, relancer IdeA, puis retester la CLI custom. Si le symptome persiste sur ce binaire date du 2026-08-05 14:40, alors seulement ouvrir une nouvelle iteration de correction sur la piste CustomAgentChatView.tsx / boucle sessionId.

2026-08-05 — Nouveau retour utilisateur apres nouvelles tentatives

• Retour utilisateur explicite: "ce n'est toujours pas bon" ; le meme symptome persiste apres plusieurs tentatives de fix.
• Symptome re-decrit par l'utilisateur: "la CLI custom s'ouvre une demie seconde puis se ferme directement vers le Plain".
• Consigne utilisateur explicite a conserver pour la suite: documenter toutes les tentatives dans ce carnet pour ne pas refaire les memes erreurs.
• Decision Main pour cette iteration: ne pas repartir sur une intuition vague ni re-appliquer la meme correction sur LayoutGrid.tsx sans preuve nouvelle. Repartir d'un cadrage Architecture puis d'une implementation ciblee avec traces d'essai consignees ici.
• Regle operative pour les prochaines entrees de carnet sur ce ticket:
  1. indiquer la commande ou la manip reelle executee,
  2. indiquer le commit/branch ou le binaire teste,
  3. indiquer le resultat exact observe,
  4. indiquer pourquoi la tentative suivante change d'hypothese au lieu de repeter la precedente.

2026-08-05 — Decision Git et instrumentation frontend

• Decision Git: ouvrir une branche dediee feature/ticket149-customchat-session-instrumentation a partir de develop au commit 4d8b69af, car cette 4e iteration change d'hypothese et ne doit pas etre melangee avec les 3 fixes precedents.
• Manip reelle cote DevFrontend: instrumentation temporaire ajoutee dans frontend/src/features/agents/CustomAgentChatView.tsx et frontend/src/features/layout/LayoutGrid.tsx, sans fix fonctionnel et sans commit pour l'instant.
• Instrumentation posee:
  1. CustomAgentChatView.tsx loggue chaque execution de openOrAttach avec timestamp, sessionId recu et compteur d'execution.
  2. CustomAgentChatView.tsx loggue debut/succes/erreur pour reattachStructuredSession, recoverStructuredSession et launchAgentChat, avec details d'erreur (code, message, name, raw).
  3. LayoutGrid.tsx loggue chaque vm.setSession avec ancienne valeur, nouvelle valeur, nodeId, cellMode, agentId et site d'appel (custom, plain, plain-background-attach, mode-switch).
  4. LayoutGrid.tsx loggue chaque evaluation de shouldFallbackCustomCliMode avec ses inputs complets et son resultat, sans modifier la logique de fallback.
• Observations techniques de cette tentative:
  • la piste LayoutGrid.tsx n'a pas ete retouchee fonctionnellement ; on evite volontairement une 4e variation speculative du meme fallback.
  • la preuve statique relevee par DevFrontend confirme que le champ session est partage entre la vue custom et la vue plain, et que CustomAgentChatView peut reecrire sessionId via onSessionIdRef.current(...) puis repasser par vm.setSession, ce qui justifie l'instrumentation de cette boucle plutot qu'un nouveau patch a l'aveugle.
• Commandes executees et resultat:
  1. git status --short --branch -> succes ; branche feature/ticket149-customchat-session-instrumentation, 2 fichiers modifies.
  2. npm run typecheck -> succes, code de sortie 0.
  3. npx vitest run src/features/agents/CustomAgentChatView.test.tsx src/features/layout/LayoutGrid.chat.test.tsx -> succes ; 2 fichiers, 16 tests.
  4. npm test -> succes ; 116 fichiers, 1096 tests.
  5. npm run build -> succes ; tsc --noEmit && vite build, 502 modules transformes.
• Particularites de sortie observees:
  • les commandes npm emettent avant script un message parasite Fatal Python error: Failed to import encodings module, mais sortent avec code 0.
  • Vitest affiche aussi des erreurs attendues de tests d'ErrorBoundary/DI et des avertissements jsdom canvas ; verdict final vert.
• Conclusion de cette tentative:
  • aucune correction fonctionnelle n'est encore appliquee ; cette iteration sert a capturer une trace exploitable sur le repro reel.
  • prochaine etape obligatoire: reproduire le bug dans l'app avec la console ouverte et filtrer les logs [ticket149] pour capturer la sequence complete (openOrAttach:start, launchAgentChat, reattachStructuredSession, vm.setSession, shouldFallbackCustomCliMode).
  • la tentative suivante devra partir de cette trace runtime et non d'une nouvelle hypothese speculative sur LayoutGrid.tsx.

2026-08-05 — Correctif minimal CustomAgentChatView/sessionId echo

• Branche reelle: feature/ticket149-customchat-session-instrumentation, depart de cette reprise sur HEAD 525ea94b, commit produit ce9ba0dc (fix(chat): ignore self-emitted custom session echoes).
• Manip/code reel:
  1. inspection statique de frontend/src/features/agents/CustomAgentChatView.tsx et du test co-localise ;
  2. correction limitee a CustomAgentChatView.tsx: separation d'un sessionId externe (externalSessionId) et des sessionId auto-emis par le composant via publishSessionId / selfEmittedSessionIdRef ;
  3. l'effet openOrAttach ne depend plus de la prop brute sessionId, donc l'echo parent d'un onSessionId(launched.sessionId) ne nettoie plus l'ouverture en cours et ne relance plus reattachStructuredSession ;
  4. aucun changement fonctionnel dans LayoutGrid.tsx.
• Test de non-regression ajoute: CustomAgentChatView.test.tsx simule un parent qui reinjecte le sessionId publie par le composant et verifie qu'un lancement neuf ne produit qu'un seul launchAgentChat et un seul reattachAgentChat.
• Commandes executees et resultat:
  1. npx vitest run src/features/agents/CustomAgentChatView.test.tsx -> succes ; 1 fichier, 8 tests.
  2. npx vitest run src/features/layout/LayoutGrid.chat.test.tsx -> succes ; 1 fichier, 9 tests.
  3. npm test -> succes ; 116 fichiers, 1097 tests.
  4. git diff --check -> succes.
  5. tentative locale git add ... && git commit ... -> echec sandbox attendu: impossible de creer .git/index.lock (Read-only file system) ; delegation a l'agent Git.
  6. agent Git -> commit cree ce9ba0dc, worktree propre, LayoutGrid non touche.
• Observation importante pendant les tests:
  • une premiere version du garde-fou a fait echouer LayoutGrid.chat.test.tsx car l'effet dependait encore de la prop brute et le cleanup React annulait l'ouverture en cours, laissant opening=true.
  • la version commitee corrige ce point en filtrant l'echo dans un effet separe et en ne relancant openOrAttach que sur changement externe effectif.
• Resultat observe:
  • preuve statique traitee: la boucle d'effet sessionId auto-emis -> parent -> prop -> openOrAttach est neutralisee.
  • validation runtime utilisateur non faite dans ce tour ; le symptome terrain doit etre reteste sur un binaire reconstruit contenant ce9ba0dc.
• Suite si le bug persiste encore en repro utilisateur:
  1. ne pas refaire une 5e variation speculative de LayoutGrid.tsx;
  2. rebuild/reinstall AppImage depuis la branche contenant ce9ba0dc, relancer IdeA, puis retester ;
  3. si la cellule retombe encore vers Plain/TUI, capturer les logs [ticket149] au moment exact du repro et comparer: openOrAttach:self-session-echo:skip, vm.setSession, shouldFallbackCustomCliMode, customCliAvailable, effectiveCustomCliAvailable, trustedCustomCli;
  4. si les logs montrent que openOrAttach reste stable, la prochaine hypothese doit sortir de CustomAgentChatView et porter sur la condition de rendu customCliAgent/customCliProfile/effectiveCustomCliAvailable ou sur un evenement externe qui remplace le mode/vue, avec trace runtime avant patch.

2026-08-05 — Nouveau symptome apres le fix session echo

• Retour utilisateur recu apres ce9ba0dc: la CLI custom peut maintenant se lancer, mais l'UI affiche l'erreur exacte not found: structured session 69b57638-0ac7-4a79-8252-e0436a3265f6.
• Changement de symptome important: on n'est plus sur la retombee immediate vers Plain/TUI telle que documentee plus haut ; on est maintenant sur un echec de rattachement/reutilisation d'une session structuree.
• Verification statique Main (sans nouvelle implementation a ce stade):
  1. frontend/src/features/agents/CustomAgentChatView.tsx est cense absorber NOT_FOUND sur reattachAgentChat puis relancer une session fraiche, y compris pour un sessionId stale restaure depuis le parent ; les tests couvrent deja ce cas.
  2. Le meme composant sait aussi recuperer d'un premier launchAgentChat qui renvoie un sessionId mort, a condition qu'un second launch/reattach reussisse ; ce cas est aussi teste.
  3. Voir quand meme cette erreur dans l'UI suggere donc plutot l'un de ces ecarts restants:
     • l'erreur reelle renvoyee par invoke(...) n'est pas typée code: "NOT_FOUND" cote frontend, donc isNotFound(...) ne la reconnait pas et elle remonte telle quelle ;
     • ou bien launch_agent renvoie lui-meme un sessionId structure qui n'est deja plus present dans structured_sessions au moment du reattach, potentiellement plus d'une fois, ce qui epuise la logique de retry et surface finalement not found: structured session ....
• Ownership provisoire pour la reprise:
  • piste prioritaire frontend/runtime contract: confirmer la forme exacte de l'erreur recue par CustomAgentChatView (code, message, name, raw) dans les logs [ticket149] deja poses ;
  • piste secondaire backend structured registry: si code === "NOT_FOUND" est bien present sur un sessionId fraichement renvoye par launch_agent, alors l'anomalie bascule cote creation/enregistrement/liveness de structured_sessions.
• Commandes de lecture executees par Main pour ce recadrage:
  1. git status --short --branch -> branche courante feature/ticket149-customchat-session-instrumentation, avec un changement non lie .ideai/idea-android-plugin.json deja present ;
  2. git log --oneline --decorate -n 12 -> HEAD 62ac05a0 au-dessus de ce9ba0dc ;
  3. lecture de frontend/src/features/agents/CustomAgentChatView.tsx, de ses tests, et de crates/app-tauri/src/commands.rs autour de reattach_agent_chat / launch_agent.
• Blocage de pilotage dans ce tour:
  • idea_ask_agent(Architect) et idea_ask_agent(Git) ont tous deux repondu You've hit your session limit · resets 4:50pm (Europe/Paris) ; la delegation specialisee est donc temporairement indisponible jusqu'au 2026-08-05 16:50 Europe/Paris.
• Etape suivante imposee a la reprise apres 16:50:
  1. refaire la delegation Architect pour trancher frontend vs backend sur ce nouveau symptome ;
  2. faire trancher Git sur la branche de travail a conserver/reprendre ;
  3. envoyer a DevFrontend une tache d'instrumentation/verification du contrat d'erreur si code manque ;
  4. envoyer a DevBackend une tache de verification de l'enregistrement/liveness structured_sessions si un sessionId fraichement lance ressort deja en NOT_FOUND ;
  5. faire valider par QA sur repro reel avec le message exact et, si possible, les logs [ticket149] au moment du repro.