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

issueRef, version, updatedBy, updatedAt

issueRef	version	updatedBy	updatedAt
#149	25	kind user	1785964173499

Historique des tentatives

2026-08-05 — Implementation frontend bornee cellKind + validation QA verte

• Pourquoi cette tentative change d'hypothese: on ne repart pas sur LayoutGrid ni sur un nouveau patch NOT_FOUND. La tentative cible explicitement le desalignement possible entre la reponse reelle de launch_agent et ce que le frontend croit lancer en session structuree.
• Manip/code reel cote DevFrontend:
  1. frontend/src/adapters/agent.ts relaie maintenant cellKind dans LaunchAgentResponse et refuse explicitement toute reponse cellKind !== "chat" dans launchAgentChat().
  2. En cas de routage non-chat, le frontend loggue [ticket149] launchAgentChat:routed-to-non-chat avec requete/reponse completes et leve STRUCTURED_ROUTED_TO_PTY avant de publier un faux sessionId structure.
  3. frontend/src/ports/index.ts borne AgentChatHandle avec cellKind: "chat".
  4. frontend/src/adapters/mock/index.ts est aligne avec cellKind: "chat".
  5. Tests ajoutes/etendus:
     • frontend/src/adapters/agent.test.ts: cas cellKind: "chat" accepte + cas cellKind: "pty" refuse.
     • frontend/src/features/agents/CustomAgentChatView.test.tsx: non-regression garantissant qu'un lancement route vers PTY ne publie pas de sessionId et n'appelle pas reattachAgentChat.
• Commandes executees par DevFrontend et resultat exact:
  1. cd frontend && npx vitest run src/adapters/agent.test.ts src/features/agents/CustomAgentChatView.test.tsx -> succes ; 2 passed, 23 passed.
  2. cd frontend && npx vitest run -> succes ; 116 passed, 1102 passed.
  3. cd frontend && npm run build -> succes ; tsc --noEmit && vite build OK.
  4. tentative de commit locale -> echec sandbox: fatal: Unable to create '/home/anthony/Documents/Projects/IdeA/.git/index.lock': Read-only file system ; aucun commit cree dans ce tour.
• Validation QA reelle sur commande:
  1. cd frontend && npx vitest run src/adapters/agent.test.ts src/features/agents/CustomAgentChatView.test.tsx -> succes ; Test Files 2 passed, Tests 23 passed.
  2. cd frontend && npm test -> succes ; Test Files 116 passed, Tests 1102 passed.
• Verdict QA: lot frontend vert sur la branche feature/ticket149-customchat-session-instrumentation.
• Resultat exact de cette tentative:
  • le frontend ne peut plus accepter silencieusement une reponse launch_agent routee en PTY comme si c'etait une vraie session chat structuree ;
  • si le runtime route en pty, l'erreur devient explicite et exploitable, sans publication de faux sessionId ni boucle de reattach impossible.
• Risque residuel maintenu explicitement:
  • ce verdict reste un verdict frontend/tests ; il manque encore la preuve runtime Tauri/AppImage du comportement reel sur un clic utilisateur, en particulier pour confirmer si le backend renvoie effectivement cellKind: "pty" dans le cas qui t'affecte.
• Etape suivante:
  • faire retester la CLI custom sur le runtime reel contenant ce diff ; selon le message exact observe, trancher entre:
    1. STRUCTURED_ROUTED_TO_PTY -> anomalie de routage/runtime a creuser ;
    2. aucune erreur mais retombee -> bug frontend post-DTO restant ;
    3. autre erreur -> nouveau symptome a classifier avec les logs [ticket149].

2026-08-05 — Reprise Main: recadrage borne pour casser la boucle

• Retour utilisateur de cette reprise: la CLI custom ne se relance toujours pas, et le probleme est confirme comme etant anterieur a la tentative de fix sur not found: structured session ....
• Commandes / manipulations reelles executees:
  1. git -C /home/anthony/Documents/Projects/IdeA status --short --branch -> succes ; branche feature/ticket149-customchat-session-instrumentation, changements uniquement .ideai/* + changement non lie .ideai/idea-android-plugin.json.
  2. git -C /home/anthony/Documents/Projects/IdeA log --oneline --decorate -n 15 -> succes ; HEAD 7071c53b, avec historique des fixes ce9ba0dc et des commits d'instrumentation/journalisation.
  3. Delegation Architect -> succes ; recadrage: ne plus traiter LayoutGrid ni le simple NOT_FOUND comme racine sans preuve runtime nouvelle.
  4. Delegation DevFrontend -> succes ; nouvelle piste concrete: l'adapter frontend ignore cellKind dans la reponse de launch_agent, alors que le backend peut router effectivement en pty.
  5. Delegation DevBackend -> succes ; confirmation que reattach_agent_chat n'est pas une cause racine et qu'un NOT_FOUND est coherent si aucune session structuree stable n'a existe.
  6. Delegation Git -> l'agent n'a pas rendu de reponse exploitable ; la decision court terme reste celle deja consignée: conserver la branche actuelle et interdire tout merge direct vers develop.
• Decision de pilotage issue de cette reprise:
  • Le message not found: structured session ... est desormais a classer comme symptome secondaire.
  • La prochaine preuve utile n'est pas un nouveau patch speculatif, mais la reponse brute de launch_agent au moment du clic CLI custom: sessionId, cellKind, assignedConversationId, engineSessionId.
• Nouvelle hypothese de travail prioritaire:
  • Si launch_agent repond cellKind: "pty", le frontend croit a tort avoir ouvert une session structuree et entre ensuite dans une boucle de reattach impossible.
  • Si aucun launch_agent n'est appele, le bug est frontend pre-launch.
  • Si cellKind: "chat" revient bien et que la vue retombe quand meme, le bug est frontend post-DTO.
• Interdictions explicites pour eviter de reboucler:
  • ne pas refaire une nouvelle variation de shouldFallbackCustomCliMode / LayoutGrid.tsx ;
  • ne pas ajouter encore du handling NOT_FOUND dans CustomAgentChatView.tsx ;
  • ne pas reconsiderer l'echo sessionId comme cause racine ;
  • ne pas pointer reattach_agent_chat tant qu'on n'a pas prouve qu'une vraie session chat a existe juste avant.
• Etape suivante imposee:
  • demander a DevFrontend un patch borne d'instrumentation/guard sur LaunchAgentResponse.cellKind pour distinguer explicitement chat vs pty au moment du lancement custom, puis faire valider ce comportement par QA sur un repro reel.

2026-08-05 — Décision Git court terme

État Git actuel

• Branche active : feature/ticket149-customchat-session-instrumentation
• HEAD courant : 7071c53b (fix frontend NOT_FOUND)
• Worktree : modifications uniquement .ideai/* (métadonnées), aucun code source

Décision Git EXPLOITABLE

1. Branche à conserver : feature/ticket149-customchat-session-instrumentation (contient ce9ba0dc et 7071c53b qui ne sont PAS dans develop)
2. Statut worktree : RISQUE MINIMAL - modifications uniquement .ideai/*, pas de conflit prévisible
3. Politique commit/merge : INTERDICTION de merge direct vers develop. STRATÉGIE : cherry-pick sélectif des fixes fonctionnels (ce9ba0dc et/ou 7071c53b) seulement quand validé, jamais les commits d'instrumentation
4. Règle anti-boucle : NE PAS retoucher LayoutGrid.tsx fallback pour une 4e fois sans trace runtime nouvelle. 3 tentatives sans effet valide, et TOUJOURS vérifier que le binaire testé contient bien les commits source (date AppImage vs date commit)

2026-08-05 — NOUVEAU RECADRAGE APRES RETOUR UTILISATEUR CRITIQUE

• Retour utilisateur: "je ne peux de nouveau plus lancer la cli custom" ET "on tourne en rond, c'etait deja le souci avant qu'on essaie de regler le message not found: structured session ..."
• Consequence decisive: le message NOT_FOUND N'EST PAS le bug source. Le bug original est revenu: la CLI custom s'ouvre 1/2 seconde puis retombe vers Plain/TUI avant meme qu'une session structurée soit créée.
• Racine architecturale identifiée: le symptôme NOT_FOUND n'était qu'un symptôme secondaire d'une tentative de reattach sur une session qui n'a jamais réussi à se stabiliser. Le vrai problème est dans le pipeline de création/initialisation de session entre l'action utilisateur et la stabilisation effective.

Hypothèses INVALIDÉES (ne plus jamais retenter):

• ✗ Fallback premature dans LayoutGrid.tsx pendant chargement catalogue (3 tentatives sans effet)
• ✗ Echo sessionId auto-émis dans CustomAgentChatView (fixé mais n'a pas résolu le symptôme)
• ✗ Absorption de la forme brute NOT_FOUND (symptôme secondaire, pas la racine)
• ✗ reattach_agent_chat backend (idempotent par design, jamais démontré fautif)

Périmètre DEVFRONTEND (nouvelle hypothèse):

• Investiger le pipeline complet d'initialisation custom — depuis l'action utilisateur jusqu'à la stabilisation de la session — en identifiant où la transition custom→Plain se produit AVANT même l'appel launch_agent.
• Vérifier particulièrement si un effet React ou une validation dans CustomAgentChatView ou LayoutGrid interrompt l'ouverture AVANT la création de session.

Périmètre DEVBACKEND (nouvelle hypothèse):

• Vérifier la logique d'initialisation de session structurée côté Rust — en particulier si launch_agent peut échouer silencieusement ou retourner un état non valide qui déclenche un fallback frontend.

Règle stricte pour les prochaines entrées de carnet:

1. Toujours vérifier si le symptôme observé se produit avant ou après la création de session structurée
2. Si avant: se concentrer sur le pipeline d'initialisation, pas sur la gestion des erreurs de session
3. Si après: alors seulement considérer la gestion NOT_FOUND / reattach
4. Documenter explicitement le point chronologique exact du fail dans chaque tentative

2026-08-05 — Nouvelle preuve runtime: returned cellKind=pty; expected chat

• Retour utilisateur exact: custom CLI launch for agent a6c6ea12-bfc6-4bdc-8031-324102dfa34d in project 97b49ac2-8376-4aa3-8ea9-bf3ac81d0023 returned cellKind=pty; expected chat. sessionId=28b18fd2-e70c-4509-a633-e57e568234d9; nodeId=3e5d083c-4d04-41d6-a4e9-2970fc5b1fd6.
• Ce que cette preuve tranche:
  • le frontend a bien envoye une intention chat et a correctement refuse une reponse backend routee en pty ;
  • le symptome n'est donc plus un fallback UI silencieux ni un NOT_FOUND tardif ;
  • la prochaine cible de correction est le routage backend/launcher humain ou le contrat de profil structured, pas LayoutGrid.tsx ni un nouveau handling frontend du NOT_FOUND.
• Retour Architecture:
  • cause probable: profil de l'agent sans structured_adapter effectif ou routage backend qui ne transforme pas l'intention cellKind:"chat" en exigence structured ;
  • cellKind cote DTO est derive de la presence d'une session structured, donc pty prouve l'absence de session structured reelle au runtime.
• Retour DevFrontend:
  • le frontend fait maintenant ce qu'on attend face a pty ;
  • le message observe vient explicitement du garde launchAgentChat() et constitue une preuve que le runtime a renvoye cellKind: "pty" a une demande chat.
• Retour DevBackend:
  • points de verite signales: crates/application/src/agent/lifecycle.rs pour le routage LaunchAgent::execute, crates/backend/src/dto.rs pour la derivation de cellKind, crates/app-tauri/src/commands.rs pour la conversion de la requete Tauri ;
  • cause probable la plus plausible: le launch humain ne propage pas toujours correctement l'intention chat jusqu'au routage structured, ce qui laisse un fallback PTY possible.
• Hypotheses INVALIDÉES supplementaires:
  • ✗ refaire un patch CustomAgentChatView pour tolérer pty ; ce serait masquer un contrat casse ;
  • ✗ revenir encore sur les effets de chargement catalogue / LayoutGrid.tsx ; la preuve runtime est plus forte ;
  • ✗ traiter sessionId=28b18fd2-e70c-4509-a633-e57e568234d9 comme une vraie session structured ; le backend a explicitement renvoye cellKind=pty.
• Règles anti-boucle a respecter desormais:
  1. Toute nouvelle tentative doit noter si le correctif vise profil/config, routing backend, ou frontend ; ne plus melanger ces pistes dans une meme iteration.
  2. Aucun nouveau patch frontend de fallback/reattach tant qu'on n'a pas prouve que le backend renvoie bien cellKind:"chat".
  3. Toute validation doit citer la commande exacte et le type de preuve: test unitaire, test integration, ou repro runtime AppImage/Tauri.
  4. Si un message futur mentionne encore returned cellKind=pty; expected chat, classer immediatement l'echec comme routage/backend ou contrat profil, pas comme regression NOT_FOUND.
• Prochaine etape imposee:
  • faire valider par QA les tests backend/frontend lies a cette propagation chat -> structured, puis demander a Git de cadrer le commit local du correctif backend si la worktree contient bien le diff correspondant.