Files
IdeA/.ideai/tickets/149/carnet.md
2026-08-05 15:23:45 +02:00

12 KiB

issueRef, version, updatedBy, updatedAt
issueRef version updatedBy updatedAt
#149 14
kind agent_id
agent a6c6ea12-bfc6-4bdc-8031-324102dfa34d
1785934744273

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.