405 Commits

Author SHA1 Message Date
a3d94d4d5e fix(layout): barre supérieure CLI custom cliquable — stacking context du corps de leaf
Le corps d'une leaf (layout-leaf-body) crée désormais son propre stacking context (z-index 0). Les vues CLI custom peuvent comporter des enfants à haut z local (toolbar z-20) qui restaient au-dessus des contrôles de cellule (CELL_Z 5) et captaient les clics ; ils restent désormais sous les contrôles. Test de layering dédié ajouté dans LayoutGrid.cellControlsLayering.test.tsx.
2026-08-06 21:57:48 +02:00
bbcb303061 merge(cli): lot CLI/TUI 2026-08-06 — #168 #169 #170 (QA verte) + #155 (contrat vert, e2e AppImage fichier non-image en attente) 2026-08-06 20:00:51 +02:00
b5b360c266 chore(tickets): QA verte lot CLI/TUI #168/#169/#170 + #155 (contrat vert, e2e AppImage fichier non-image en attente) 2026-08-06 20:00:36 +02:00
8e97da57c9 fix(cli): bouton Send↔Stop #168 + collage clipboard fichier générique #155 2026-08-06 20:00:36 +02:00
292a81ee60 fix(backend): disponibilité session user + hand-off CLI↔TUI sans collision — #169 #170 2026-08-06 20:00:36 +02:00
c50b6c5388 chore(tickets): sync miroir — lot CLI/TUI #155/#168/#169/#170 (+ clôture #151/#167)
(cherry picked from commit d7c4505bacdb9bc03145f12267ae281ad6a35739)
2026-08-06 19:40:46 +02:00
31976d6ed8 fix(cli): collage presse-papiers image/fichier via clipboardData.files — #155 (partiel : logique+tests verts, e2e AppImage clipboard en attente)
(cherry picked from commit 2f39a5ce17b9895e683c0d48f0d9e034e701ed19)
2026-08-06 19:40:46 +02:00
d1e6ae1a22 chore(memory): màj note topologie cycle #151/#167/#155 (issue finale) 2026-08-06 19:16:30 +02:00
0390d18214 chore(tickets): clôture #151 #167 (QA verte) — sync miroir; #155 reste ouvert (e2e AppImage en attente) 2026-08-06 19:14:12 +02:00
9f05ad6aa6 merge(cli): intègre #151 #167 (QA verte) — z-order Cancel + projection live événements avant Final 2026-08-06 19:10:02 +02:00
b45deabe6d fix(cli): z-order Cancel #151 + projection live événements avant Final #167 (+ alignement fixture plugin #165/#166) — QA verte 2026-08-06 19:09:07 +02:00
3d4ea6859e chore(tickets): rouverture #151 #155 + création #167 — sync miroir tickets 2026-08-06 18:50:52 +02:00
e148d3cc5e chore(tickets): clôture #165 #166 + épic #161 — sync miroir tickets
#165 (seam plugin slash-commands) et #166 (dispatch e2e du callback plugin)
fermés après merge de feature/165-plugin-slash-commands dans develop.
L'épic #161 (commandes slash custom CLI) est entièrement terminé : tous ses
sous-tickets (#162 fondation, #163 autocomplete, #164 /profile, #165 seam
plugin) plus le dispatch e2e (#166) sont intégrés.
Sync du miroir local + counter (#166 créé).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-06 15:47:46 +02:00
f6d2a37a97 merge(plugins): intègre feature/165 — seam #165 + dispatch e2e #166 (QA verte)
Clôture l'épic slash-commands #161 : avec le seam plugin (#165) et le dispatch
end-to-end du callback (#166), tous les sous-tickets natifs + plugin sont livrés.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-06 15:47:19 +02:00
b0be5f04e4 feat(cli): dispatch du callback plugin slash-command vers le runtime registry — #166 (QA verte)
Boucle le gap end-to-end de #165 : à l'exécution d'une commande slash plugin
depuis le composer custom, l'UI traite l'effet pluginCallback et le dispatche
au PluginRuntimeRegistry pour que la callback du plugin s'exécute réellement.

- runtime/registry: runCommandStrict (échec explicite si handler absent) +
  propagation de la valeur de retour ; élargit les types de retour (unknown).
- runtime/loader: chargement de contributes.slashCommands au registre +
  propagation du retour du handler.
- features/plugins/usePluginMenus: runCommand retourne unknown.
- features/agents/CustomAgentChatView: handler de l'effet pluginCallback ->
  pluginRuntime.registry.runCommandStrict, avec retour utilisateur en cas
  d'échec (commande indisponible / callback absente).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-06 15:47:04 +02:00
fbaca9d5cc feat(plugins): seam slash-commands contribuées par plugin via callback — #165 (QA verte)
Permet à un plugin de contribuer des commandes slash adossées à une callback,
transitant par le registry/contrat unifié (#162) :

- sdk/IdeaSDK: manifeste contributes.slashCommands (déclaratif) — pointer bumpé.
- domain: source Plugin étendue + effet PluginCallback (la commande ne
  s'exécute pas directement : elle renvoie une référence à la callback du plugin).
- application: registration des commandes plugin dans le registry + exécution
  renvoyant l'effet PluginCallback ; métadonnées UI suffisantes pour l'autocomplete.
- backend + app-tauri: DTO + commandes Tauri listant/invoquant les commandes plugin.
- frontend (contrat): types adapters/domain/ports/mock pour pluginCallback et
  l'invocation avec arguments.

L'exécution effective de la callback côté runtime UI est livrée par #166.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-06 15:46:52 +02:00
ff7696b724 chore(tickets): clôture #164 (QA verte) — sync miroir tickets
#164 (/profile + reset de session confirmé) fermé après merge de
feature/164-profile-command dans develop. Sync du miroir local.
Reste #165 (seam plugins) pour clore l'épic #161.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-06 15:12:24 +02:00
4ebf125ec6 merge(cli): intègre feature/164-profile-command — /profile + reset confirmé #164 (QA verte)
Commande /profile first-class avec reset de session explicite et confirmé,
séparée de la palette slash générique. Dernier sous-ticket de l'épic #161
avant #165 (seam plugins).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-06 15:12:07 +02:00
2cd8df4a4e feat(cli): commande /profile + sélection de profil avec reset de session confirmé — #164 (QA verte)
Ajoute /profile comme commande slash first-class dont la sémantique de reset
de session reste explicite et testable, séparée de la palette générique :

- domain + application: /profile est enregistrée et renvoie un effet
  SlashCommandEffect::ProfileSwitch { session_id }. La commande ne reset pas
  directement : elle délègue l'effet au frontend pour imposer une confirmation.
- frontend (CustomAgentChatView): à l'exécution de /profile, ouverture d'un
  popup de sélection de profil informant que la validation reset la session,
  avec confirmation explicite (confirmedReset) requise avant changeAgentProfile.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-06 15:12:00 +02:00
a6ba3ff6e1 chore(tickets): clôture #163 (QA verte) — sync miroir tickets
#163 (UX autocomplete slash-commands) fermé après merge de
feature/163-slash-command-autocomplete dans develop. Sync du miroir local.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-06 15:03:04 +02:00
c42ba63c28 merge(cli): intègre feature/163-slash-command-autocomplete — menu slash-commands #163 (QA verte)
UX d'autocomplétion slash dans le composer custom, consommant le contrat
unifié de #162 (aucune liste codée en dur). Débloque #164 (/profile).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-06 15:02:49 +02:00
853d8229f2 feat(cli): menu contextuel d'autocomplétion des slash-commands dans le composer — #163 (QA verte)
À la saisie d'un « / » en début de draft (sans espace), ouverture d'un menu
contextuel listant les commandes matchant le préfixe, via le contrat unifié
listSlashCommands — aucune liste codée en dur côté UI. Rafinement incrémental
des suggestions à la frappe, navigation clavier + sélection, exécution par
executeSlashCommand.

- adapters/agent: listSlashCommands(prefix?) + executeSlashCommand (invoke Tauri).
- domain + ports: types SlashCommand / ExecuteSlashCommandResult.
- mock: données de test.
- CustomAgentChatView: détection de préfixe (/ sans espace), fetch avec séquence
  anti-retard, gestion ouverture/active index, navigation clavier, fermeture
  quand le préfixe cesse d'être éligible.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-06 15:02:40 +02:00
b51011d206 chore(tickets): clôture #162 (QA verte) — sync miroir tickets
#162 (fondation slash-commands) fermé après merge de
feature/162-slash-commands-foundation dans develop. Sync du miroir local.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-06 14:53:04 +02:00
6c558cc0af merge(slash): intègre feature/162-slash-commands-foundation — fondation commandes slash #162 (QA verte)
Contrat unifié slash-command (domain + application registry + wiring
backend/app-tauri) avec /help et /clean natifs. Débloque #163, #164, #165.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-06 14:52:44 +02:00
6997138a71 feat(slash): fondation du système de commandes slash pour la CLI custom — #162 (QA verte)
Introduit le contrat unifié des commandes slash consommable par le frontend,
indépendant de la source (native, puis plugin plus tard) :

- domain: modèle pur SlashCommand / SlashCommandSource / SlashCommandAvailability,
  métadonnées UI (nom, description, disponibilité, confirmation requise) et
  validation des noms/préfixes.
- application: registry + list/filter par préfixe + plan d'exécution natif ;
  commandes natives /help et /clean (/clean = nettoyage de la vue de session
  courante ; pas de /reset distinct tant qu'aucune utilité produit ne le justifie).
- backend + app-tauri: exposition du contrat via DTO/transport + tests DTO.

Source neutre : les commandes contribuées par plugins (#165) transiteront par
le même registry sans changer le contrat frontend.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-06 14:52:36 +02:00
4e57161e1d chore(tickets): clôture #151 #157 (QA verte) — sync miroir tickets
#151 (z-order bouton Cancel) et #157 (arrêt spinner Progress) fermés
après merge du Cluster A (fix/batch-151-157-cli-ui) dans develop.
Sync du miroir local .ideai/tickets.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-06 14:30:13 +02:00
102c003405 merge(ui): intègre fix/batch-151-157-cli-ui — fixes #151 #157 (Cluster A, QA verte)
#151: z-order du bouton Cancel en état busy (LayoutGrid).
#157: arrêt du spinner Progress à l'état terminal (CustomAgentChatView).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-06 14:29:49 +02:00
57ced6801b fix(cli): arrêt du spinner Progress à l'état terminal — #157 (QA verte)
Ajoute completeRunningProgress() qui passe les stages started/delta à
completed lors des événements final/error. La ligne Progress conserve son
contenu statique utile mais n'affiche plus l'animation de chargement une
fois le tour terminé.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-06 14:29:39 +02:00
a9346476ee fix(layout): bouton Cancel en z-order propre pendant un tour agent — #151 (QA verte)
Extrait le bouton Cancel du banner inline et le rend en position absolue
(top:24, right:20) avec zIndex CELL_Z.turnActions. Le banner de statut est
décalé (right:76 en état busy) et rétrogradé en CELL_Z.banner, afin que
Cancel reste au premier plan et cliquable sans recouvrement en état busy.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-06 14:29:31 +02:00
0f60f625a1 chore(tickets): réouverture #151 #157 + création epic slash-commands #161–#165
Réouvre #151 (résidu z-order bouton Cancel en état busy) et #157 (suivi UX :
arrêt du spinner à l'état terminal) en statut open avec assignations.
Crée l'epic slash-commands custom CLI : #161 (ombrelle suivi produit),
#162 (fondation registry + /help + /clean), #163 (UX autocomplete / menu),
#164 (/profile + reset session confirmé), #165 (commands contribées plugins).
nextNumber 161 → 166.

Bookkeeping tickets seul (l'état runtime .ideai hors-lot reste en working
tree, non committé).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-06 14:19:04 +02:00
380fefd37b chore(tickets): clôture #151 #156 #157 #160 — sync tickets/mémoire (QA verte) 2026-08-06 13:14:01 +02:00
03303aa276 fix(ui): toolbar CLI sans overlap + retrait du bouton History — #151 #160 (QA verte) 2026-08-06 13:13:30 +02:00
309c10e5e9 feat(cli): surface progression intermédiaire, activité MCP, flux agent↔agent — #157 (QA verte) 2026-08-06 13:13:24 +02:00
918116664c feat(backend): modèle unifié streaming/progress/events provider-agnostic + pont app-tauri — foundation #156 (QA verte) 2026-08-06 13:13:17 +02:00
40fa551f32 merge(chat): intègre feature/155-clipboard-paste-image — paste image clipboard dans le composer (#155, QA verte) 2026-08-06 11:01:50 +02:00
790c4755be feat(chat): #155 paste image depuis presse-papier dans le composer custom (QA verte)
- frontend: onPaste sur CustomAgentChatView, détection MIME image, chip/preview d'attachment, envoi via le contrat #154 (adapters/agent, ports)

- backend: import d'image par bytes dans le store attachments (commands, chat_attachments app+infra, dto, ports) + tests
2026-08-06 11:01:50 +02:00
88dfbfe471 merge(attachments): intègre feature/154-attachments-pipeline — fondation pipeline durable d'attachments agent/chat (#154, QA verte) 2026-08-06 10:44:15 +02:00
1c80d08f92 feat(attachments): fondation pipeline durable d'attachments agent/chat + sandbox-safe (#154, QA verte)
Socle #154 : entité attachment, store, contrat DTO et routage session. Modules : domain/chat_attachment, application/chat_attachments, infrastructure/chat_attachments, app-tauri (commands/lib), backend dto.
2026-08-06 10:44:15 +02:00
560b5ae7d1 merge(ui): intègre fix/batch-151-158-159-ui — fixes #151 #158 #159 (Lot A, QA verte) 2026-08-06 10:23:23 +02:00
c5d6c3b98e fix(ui): Lot A #151 #158 #159 (QA verte)
- #151: chevauchement des boutons dans la barre supérieure pendant une conversation agent

- #158: popup de reprise de conversation intempestive (ajout cellule / changement layout / projet)

- #159: pastille d'activité de projet
2026-08-06 10:23:23 +02:00
fb19ee48dc chore(tickets): met à jour le timestamp index.json 2026-08-05 23:44:51 +02:00
ee35c15958 chore(tickets): journalise le correctif routing chat vs PTY #149
- Met à jour le carnet avec la preuve runtime returned cellKind=pty; expected chat
- Documente les hypothèses invalidées et la nouvelle cible de correction
- Met à jour issue.md avec le titre et le diagnostic consolidés
- Incrémente le compteur et ajoute les tickets 150-158 à l'index

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 23:40:03 +02:00
937ea07df1 feat(chat): valide le routing cellKind=chat côté frontend et corrige UX
- Ajoute cellKind dans AgentChatHandle et vérifie que launchAgentChat reçoit cellKind:chat
- Rejette avec erreur STRUCTURED_ROUTED_TO_PTY si le backend route vers PTY
- Ajoute cellKind:chat dans MockAgentGateway.launchAgentChat
- Corrige l'overflow du layout CustomAgentChatView (bounded shell avec scroll + composer fixe)
- Dédouble les prompts utilisateur quand le stream les echo
- Ajoute les tests launchAgentChat returns handle only when confirms chat et launchAgentChat rejects PTY-routed launch
- Ajoute les tests does not duplicate user prompt when echoed et keeps chat shell bounded

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 23:39:50 +02:00
c43f29b2f2 feat(chat): propage l'intention chat → require_structured dans le pipeline de lancement
- Ajoute le champ cell_kind dans LaunchAgentRequestDto pour distinguer les demandes chat (custom CLI) des lancements PTY historiques
- Convertit cellKind:Chat en require_structured:true dans commands.rs et web-server/src/lib.rs
- Implémente la logique de routing structuré dans LaunchAgent::execute :
  - valide que require_structured implique un profil avec structured_adapter
  - remplace une session PTY existante quand require_structured est vrai
  - route vers structured seulement quand wants_structured est vrai
- Met à jour tous les appels historiques avec require_structured:false pour préserver le contrat PTY
- Ajoute les tests unitaires human_launcher_with_chat_intent_routes_structured_profile_to_chat_session et chat_intent_replaces_existing_pty_instead_of_returning_pty_session
- Wire les ports structured dans BackendCore pour le launcher humain

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 23:39:35 +02:00
7071c53bb2 fix(chat): handle raw structured session NOT_FOUND errors from Tauri
Elargit isNotFound() pour reconnaitre aussi la forme brute
'not found: structured session <uuid>' que Tauri peut retourner,
en plus de la forme typée {code: 'NOT_FOUND'}.

Ajoute deux tests couvrant:
- fallback sur reattach avec erreur brute
- retry prompt sur send avec erreur brute

QA: tests passés sur cette correction.
2026-08-05 16:00:37 +02:00
62ac05a080 chore(tickets): journalise le correctif session echo #149
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 15:30:08 +02:00
ce9ba0dc3d fix(chat): ignore self-emitted custom session echoes
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 15:29:03 +02:00
525ea94b09 chore(tickets): journalise le recadrage #149
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 15:23:45 +02:00
029ed97bff chore(chat): instrumentation session CustomAgentChatView pour diagnostic #149
Ajoute des points de traçage ciblés sur le cycle de vie de session
CustomAgentChatView/LayoutGrid pour isoler la cause du fallback
silencieux CLI custom avant tentative de fix.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 15:23:45 +02:00
4d8b69afca chore(tickets): recadre #149 — instrumentation ciblée CustomAgentChatView/session au lieu d'une 4e variation LayoutGrid
Consigne Architecte: le fallback custom→TUI persiste après 3 correctifs sur
LayoutGrid.tsx. Nouvelle piste non explorée: boucle d'effet sessionId dans
CustomAgentChatView.tsx (openOrAttach déclenché par son propre callback
onSessionId). Carnet mis à jour avec l'historique complet des tentatives et
la règle de traçabilité demandée par l'utilisateur.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 14:50:33 +02:00
66b9c34bc3 merge(chat): intègre feature/ticket149-reopen-frontend-refetch — stabilise CLI custom vs refetch stale (#149, QA verte)
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-05 14:25:03 +02:00
e9e4623ecf fix(chat): stabilise le mode CLI custom contre le refetch stale agents/profiles (#149)
Le fallback custom→TUI se redéclenchait après le premier chargement dès que
refreshProfiles() renvoyait un instant un profil pinné sans structuredAdapter
(refetch en vol), coupant la CLI custom ~0.5s après son ouverture. Introduit
un binding "trusted" (agent+profil validés) qui reste valide tant qu'aucun
changement légitime de profil n'est observé via agentProfileChanged, et ne
retombe en TUI que sur perte réelle du CLI custom.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-05 14:24:55 +02:00
0e2fc83689 chore(tickets): réouvre #149 — le fallback silencieux CLI custom persiste après retest
Retest utilisateur du 2026-08-05: la CLI custom s'ouvre ~0.5s puis retombe
sur Plain/TUI malgré le fix précédent. Statut repassé à open pour relancer
le cycle de diagnostic/correction.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-05 14:17:00 +02:00
3ae616bad9 merge(chat): intègre feature/ticket149-cache-stale-agents-profiles — fix cache stale agents/profiles (#149, QA verte)
QA verte : LayoutGrid.chat.test.tsx (7 tests), src/features/layout (16 fichiers, 130 tests).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 14:06:27 +02:00
61055779c4 fix(chat): retarde le fallback custom→TUI tant que le catalogue agents/profiles est stale (#149)
Cause racine restante après le fix de la course au premier chargement : le
garde-fou de LayoutGrid retombait sur `tui` dès que agents/profiles semblaient
indisponibles, y compris quand le cache était simplement stale (refresh en
cours), écrasant silencieusement la préférence custom. Le fallback n'agit
désormais qu'une fois le catalogue confirmé à jour.

QA verte : LayoutGrid.chat.test.tsx (7 tests), src/features/layout (16
fichiers, 130 tests), cas ciblé "stale catalog refresh".

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 14:06:18 +02:00
fa518415c6 merge(chat): intègre feature/ticket149-custom-cli-silent-fallback — fix fallback silencieux CLI custom → Plain (#149, QA verte)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 13:48:35 +02:00
0103a8acf6 chore(tickets): clôture #149 — QA verte sur feature/ticket149-custom-cli-silent-fallback
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 13:48:30 +02:00
dedc3b5134 test(chat): couvre le fallback TUI si le catalogue invalide le profil pinné (#149)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 13:48:27 +02:00
51bda20455 fix(chat): preserve custom CLI preference during catalog load (#149)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 13:45:41 +02:00
9d18d01380 chore(tickets): ouvre le ticket #149 (fallback silencieux CLI custom → Plain)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 13:41:30 +02:00
ecad746c66 chore(tickets): synchronise les statuts tickets et l'état plugin android
Rattrapage de l'état runtime .ideai/ (tickets #119-#139/#147 clôturés,
compteur→149, ticket #148 clos et QA verte, métadonnées plugin android) —
séparé du code de feature avant d'ouvrir le travail sur le nouveau bug
de lancement CLI custom.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 13:40:44 +02:00
00a2eaaa16 merge(chat): intègre fix/ticket148-structured-session-not-found — relance propre sur reattach mort (#148, QA verte)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 13:17:39 +02:00
e80f7631ff fix(chat): relance propre au lieu de re-tenter l'attach sur une session structurée morte (#148)
Sur reattach NOT_FOUND, le composant retentait implicitement l'attach sur le
même sessionId mort au lieu de nettoyer l'état avant de relancer, ce qui
produisait l'erreur "not found: structured session …" côté utilisateur.
recoverStructuredSession() nettoie désormais sessionId/conversationId avant
de relancer et retente une seule fois le reattach sur NOT_FOUND post-launch.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 13:17:31 +02:00
fab172094a merge(chat): intègre fix/ticket147-structured-session-reattach-fallback — fallback fresh launch sur reattach mort (#147, QA verte)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 12:11:46 +02:00
b37542107a fix(chat): fallback vers un nouveau lancement quand la session structurée reattach est morte (#147)
reattachAgentChat pouvait échouer avec NOT_FOUND (session structurée fermée
ou jamais vivante) et laisser fuiter l'erreur brute jusqu'à l'utilisateur
("not found: structured session ... not found") au lieu de relancer une
session fraîche. Le fallback ne s'applique qu'au code NOT_FOUND ; toute
autre erreur de reattach continue de remonter telle quelle.

QA vert 2026-08-05 : npx vitest run CustomAgentChatView.test.tsx,
npx vitest run agents.test.tsx CustomAgentChatView.test.tsx, npm run typecheck.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 12:11:38 +02:00
c0764d6a0c merge(orchestrator): intègre feature/ticket147-custom-chat-cli — CLI custom de chat agent (#147, QA verte)
Livraison complète : toggle TUI/CLI custom par cellule, socle backend
AgentSession/ChatBridge, et correctif du bouton Cancel (interruption du
tour courant au lieu de fermer la session). QA a validé en vert après
le correctif frontend ciblé.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 12:00:05 +02:00
dcba76b871 feat(chat): livre la CLI custom de chat agent (#147) et corrige Cancel
Implémente la vue chat structurée par cellule agent (toggle TUI/CLI custom,
préférence persistée `preferred_view`, reattach live, composer + pièces
jointes) avec le socle backend AgentSession/ChatBridge (UserPrompt,
cancel_current_turn, routage interrupt_agent, commande cancel_agent_chat).

Corrige le bug bloquant relevé par QA : le bouton Cancel de
CustomAgentChatView interrompait tout le tour via closeAgentChat au lieu
de n'annuler que le tour courant via cancelAgentChat, ce qui tuait la
session contrairement au contrat produit validé.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-05 11:59:39 +02:00
efbd56a149 chore(tickets): sync carnets/issues #102/#141-#147 + agent glmopencode
Rebase de l'état ticket (réouverture #102, clôtures #141-146, ouverture
#147) et ajout du contexte agent glmopencode avant démarrage du cycle #147.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-04 23:57:30 +02:00
1c53ee09ef merge(orchestrator): intègre feature/fix-ask-agents-background-task-store — fix background task store (idea_ask_agents, tests verts)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-04 12:26:38 +02:00
c1267bf880 fix(infrastructure): corrige le background task store utilisé par idea_ask_agents
Le store de tâches d'arrière-plan produisait un état incohérent lors de la
délégation multi-agent via idea_ask_agents. Tests ciblés ajoutés/étendus,
suite verte.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-04 12:26:33 +02:00
d997aba288 merge(orchestrator): intègre feature/glm-opencode-delegation-fix — fix délégation GLM/OpenCode (QA verte)
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-04 09:50:06 +02:00
b88d500d89 fix(orchestrator): corrige la delegation inter-agent GLM/OpenCode sans reponse Final
La detection d'absence de reponse structuree finale (structured_no_reply_error)
ne couvrait pas AgentSessionError::Decode ni le message "aucun final textuel
exploitable" emis par l'adaptateur OpenCode, ce qui laissait idea_ask_agent
planter silencieusement sur les profils GLM/OpenCode au lieu de retomber sur
le chemin de secours prevu.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-04 09:50:02 +02:00
11c405efea merge(window): intègre feature/plugin-hosted-windows — fenêtres plugin-hébergées #142-146 (vert QA)
Backend (window usecases + commande Tauri), frontend (host de fenêtre +
services.windows.open), runtime SDK (react/react-dom résolus vers l'host) et
documentation SDK restructurée. QA verte (cargo + vitest + typecheck + build
+ sdk check) ; réserve non bloquante : pas d'e2e natif clic sous-menu ->
fenêtre OS.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-04 00:40:16 +02:00
5a64e7fd5b chore(sdk): pointe le submodule sur develop (post-merge feature/plugin-hosted-windows)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-04 00:40:16 +02:00
13bad558ba chore(tickets): synchronise carnets/statuts #142-146 (QA verte) + bump IdeaSDK
QA verte sur feature/plugin-hosted-windows : cargo (domain/application/
infrastructure/app-tauri), frontend (vitest/typecheck/build), sdk npm check.
Réserve non bloquante : pas d'e2e natif complet clic sous-menu -> fenêtre OS.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-04 00:39:57 +02:00
d8df466fba feat(frontend): host les fenêtres plugin et l'API publique windows.open
Ajoute la vue window host qui charge le layout plugin dans une fenêtre OS
détachée, expose react/react-dom/jsx-runtime hébergés sous
frontend/public/plugin-host pour que le runtime SDK y résolve React, et
câble services.windows.open() côté runtime plugin (loader/services/registry).

npm test -- --run src/adapters/window.test.ts src/app/ViewWindow.test.tsx
  src/plugins/runtime/loader.test.ts src/plugins/runtime/services.test.ts : 39/39
npm run typecheck : OK
npm run build : OK

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-04 00:39:50 +02:00
551eb09ad2 feat(window): support des fenêtres plugin-hébergées (backend)
Étend le port/usecases window et layout.customPluginLayout pour ouvrir et
piloter des fenêtres OS hébergeant un layout plugin, en réutilisant
contributes.layouts plutôt qu'un système de fenêtres parallèle. Câble la
commande Tauri et l'état app-tauri correspondants.

Cargo test -p domain --test window : 5/5
Cargo test -p application --test window_usecases : 7/7
Cargo test -p infrastructure --test window_state_store : 1/1
Cargo test -p app-tauri view_window_tests : 8/8

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-04 00:39:42 +02:00
3ea1d58b38 chore(ideai): sync tickets #142-146 (SDK plugin windows) + contexte git + bump IdeaSDK
Enregistre le cadrage du programme fenêtres plugin-hébergées (#142 backend,
#143 frontend host + windows.open, #144 runtime React partagé, #145 docs SDK,
#146 QA) et met à jour le contexte de l'agent Git avec le modèle de branches
git-flow simplifié.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-04 00:10:00 +02:00
78dc888bd9 merge(layout): intègre ticket141-plugin-layout-create-support — création de layouts plugins (vert QA) 2026-08-03 18:34:24 +02:00
45617992ef feat(layout): supporte la création de layouts plugins (customPluginLayout)
Étend le flux de création de layout backend (DTO, usecases, store) et le
frontend (sélecteur, adaptateurs, LayoutTabs/LayoutGrid) pour permettre
d'ouvrir un layout déclaré par un plugin installé (ex. Android Health),
sans passer par le message bloquant "extension backend pas encore livrée".

Ticket #141 — QA vert.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-03 18:34:21 +02:00
168f93df78 merge(context): intègre fix-context-read-canonical-path — idea_context_read pointe .ideai/CONTEXT.md (vert QA) 2026-08-03 14:58:30 +02:00
70712a35f8 fix(context): route idea_context_read vers .ideai/CONTEXT.md au lieu de CLAUDE.md
La lecture du contexte projet global via MCP (idea_context_read sans target)
lisait <root>/CLAUDE.md au lieu de la source de vérité canonique
<root>/.ideai/CONTEXT.md, désynchronisant la lecture MCP de
crates/application/src/project/context.rs. ReadContext, UpdateProjectContext
et ProposeContext partagent désormais project_context_path/project_context_dir,
avec création du dossier .ideai/ à l'écriture et lecture tolérante à l'absence
du fichier (FsError::NotFound -> contenu vide).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-03 14:58:22 +02:00
3fa9691cd6 merge(batch): intègre plugin-activation-scope-loading — chargement du scope d'activation des plugins (vert QA) 2026-08-03 14:44:23 +02:00
6a86b3ad80 chore(ideai): sync tickets #43/#140 + skills index + agent context
Ticket #43 carnet reflects activationScope in the plugin manifest
example; ticket #140 closed; skills index/content refreshed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-03 14:44:12 +02:00
e2da2d911e feat(plugins): load activation scope from plugin manifest
Plugins can now declare activationScope ("app" | "project") in their
manifest; loader/runtime honor it to defer activation of project-scoped
plugins until a project is focused instead of activating everything at
app bootstrap. Bumps sdk/IdeaSDK to the commit that adds the field.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-03 14:44:08 +02:00
863d9b7277 fix(agents): unwrap read_agent_context DTO content (#140)
Le contexte projet d'un agent s'affichait "[object Object]" et se
vidait à la réouverture du panneau : read_agent_context renvoie déjà
{content} côté backend, mais les gateways front traitaient la réponse
comme une string brute. Les deux gateways (Tauri + HTTP) unwrap
maintenant .content ; type AgentContextDocument ajouté au domaine.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-03 14:35:36 +02:00
cf61060ffb chore(tickets): sync statuts/carnets #113/#119/#120/#122/#131/#132 + bump IdeaSDK ESM (#134/#139)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-03 12:44:20 +02:00
59d81851e9 chore(tickets): synchronise index/carnets tickets #131-#139 + note mémoire assets/persistance plugins
État runtime .ideai séparé du code (index, counter, carnets, note mémoire
plugin-asset-serving-and-owned-storage-contracts). Purge des tickets obsolètes
51/63/66.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-03 11:06:30 +02:00
171c6c923c feat(wave): #119/#122/#131/#132 verts + sprint plugins ESM/persistance #135/#136/#139
État d'intégration confiné à la branche batch. Les tickets #119 (skills →
capacités agent découvrables), #122 (override permissions par défaut), #131
(effort par agent/presets) et #132 (outil MCP d'édition du contexte projet)
sont verts en périmètre. Le sprint plugins multi-fichiers ESM / persistance
plugin-owned (#135/#136/#139) est co-implémenté dans les MÊMES fichiers de
câblage (frontend/src/ports/index.ts, backend/src/lib.rs, domain/ports.rs,
backend/dto.rs), inséparable sans staging interactif (indisponible ici).

Commit unique volontaire : préserve l'état vert QA sans découpe hunk risquée.
NON mergé vers develop tant que #137 (QA e2e plugins) n'est pas vert.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-03 11:06:23 +02:00
7497fe19aa merge: intègre #113 — champ args llamacpp ne capture plus les frappes (vert QA)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-03 10:51:55 +02:00
0a52005afb fix(model-servers): empêche la capture des touches dans le champ args du serveur llamacpp (#113)
Les espaces et autres frappes étaient interceptés par un handler parent ;
stopPropagation sur le onKeyDown de l'input args laisse la saisie intacte.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-03 10:51:47 +02:00
22c6bd803d merge(batch): intègre #134 — service confiné multi-fichiers ESM (vert QA)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-03 00:02:11 +02:00
71d08795d9 feat(plugins): sert tout fichier confiné du package installé (multi-fichiers ESM) (#134)
Implémente §22.1 : asset_allowed autorise tout chemin relatif dès lors que
les gardes déjà en place sont satisfaites (entrée registre active,
content_hash du package, confinement canonicalize en aval), au lieu de
restreindre au triplet main/icon/assets. Débloque les imports ESM
multi-fichiers (./constants.js, ./core/x.js) sans affaiblir le modèle de
menace fixé à l'install (#135).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-02 23:47:41 +02:00
2f1d99c5e1 merge(batch): intègre #138 — §22.2 persistance plugin-owned hors projet
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-02 22:52:18 +02:00
a5e56885d9 docs(architecture): §22.2 — persistance plugin-owned hors projet & purge à la désinstallation (#138)
Cadrage architecture du ticket #138 : séparation project-owned/plugin-owned,
API canonique ctx.storage seule, stockage sous app_data/plugins/data/<id>/
(frère de installed/), purge intégrale à l'uninstall. Débloque #139.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-02 22:52:13 +02:00
1b9915c229 merge(batch): intègre #133 — §22.1 contrat de service des assets multi-fichiers ESM
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-02 22:52:00 +02:00
fa474ae97f docs(architecture): §22.1 — contrat de service des assets idea-plugin:// multi-fichiers ESM (#133)
Cadrage architecture du ticket #133 : asset_allowed autorise tout chemin
relatif confiné dès lors que registre actif + content_hash + confinement
canonicalize sont satisfaits, sans gater fichier par fichier. Débloque
#134/#135.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-02 22:51:53 +02:00
7c2bd227d2 fix: Codex PTY launch forwards profile model as argv override
- injecte model et model_reasoning_effort du profil via -c dans argv
- remplace le modèle TUI stale en config.toml
- aligne PTY/interactif sur le comportement déjà garanti par CodexExecSession
- test unitaire codex_pty_launch_forwards_profile_model_as_config_override
2026-08-02 18:02:00 +02:00
dcc7a6f216 fix: project model and reasoning_effort into Codex CLI args, stop rewriting .codex/config.toml
- Add model_reasoning_effort field to AgentProfile (domain layer)
- Remove model parameter from codex_config_toml, stop rewriting model in TOML
- Pass model and model_reasoning_effort via Codex CLI -c overrides on every exec
- Update CodexExecSession with new_with_policy_and_overrides factory
- Cover new conversation and resume flows with tests
2026-08-02 17:19:26 +02:00
b730e356aa refactor(sdk): remplace dépôt imbriqué par git submodule
- Convertit sdk/IdeaSDK en git submodule pointant vers IdeaSDK dédié
- Nettoie les artefacts du dépôt git imbriqué (.git.disabled-empty-nested-repo)
- Le SDK TypeScript plugin est maintenant dans son propre repo

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-02 16:33:50 +02:00
6959fbbe9a Merge branch 'feature/sdk-plugin-tooling-build-debug-surface' into develop 2026-08-02 13:37:02 +02:00
a051b5299a chore(tickets): mise à jour index et tickets SDK plugins #123-#130 2026-08-02 13:36:43 +02:00
8c4f1ea2e3 feat(sdk,plugins): typage et stabilisation runtime UI/layout publique (#128) 2026-08-02 13:36:17 +02:00
e3e887d6a4 feat(sdk,plugins): APIs publiques lancement commandes + outillage + événements + config (#125,#126,#127,#130) 2026-08-02 13:35:48 +02:00
dce61ae1aa feat(sdk,plugins): API publique d'accès fichiers/workspace + analyse structure (#124,#129) 2026-08-02 13:34:54 +02:00
80c9e0a236 merge feature/sdk-plugin-tooling-build-debug-surface dans develop
feat(sdk,plugins): ajoute capability tooling et services runtime publics (workspace/terminal/tasks)
- capability manifeste tooling supportée backend + transport runtime catalog
- ctx.services publique côté SDK/runtime, gated par tooling
- surface honnête: workspace, terminal, et tasks en observation/contrôle uniquement
- docs/exemple/tests mis à jour
- QA PASS
2026-08-02 00:31:40 +02:00
033e9a86d5 feat(sdk,plugins): ajoute capability tooling et services runtime publics (workspace/terminal/tasks)
- capability manifeste tooling supportée backend + transport runtime catalog
- ctx.services publique côté SDK/runtime, gated par tooling
- surface honnête: workspace, terminal, et tasks en observation/contrôle uniquement
- docs/exemple/tests mis à jour
- QA PASS sur feature/sdk-plugin-tooling-build-debug-surface
2026-08-02 00:31:15 +02:00
efaeb31a38 docs(tickets): consigne le cycle #120 fix CORS + décision Git et états (#120)
- carnet.md: enregistre la livraison CORS et la décision Git du 2026-08-01
- issue.md + index.json: mise à jour version/timestamp
- plugins.test.tsx: tests d'intégration frontend liés
- Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-01 19:12:39 +02:00
a88307c5ff refactor(frontend,plugins): normalise les DTOs review backend et corrige le mock (#120)
- plugin.ts: normalizeReview() garantit issues/installable définis même si backend omet ces champs
- mock/index.ts: MockPluginGateway.uninstall() retourne removalOutcome pour cohérence avec le domaine
- domain/index.ts: PluginUninstallResult ajoute removalOutcome optionnel
- Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-01 19:12:16 +02:00
5baf5821d4 test(backend,plugins): ajoute un test de non-résidu runtime après uninstall/reinstall (#120)
- plugin_install_load.rs: test uninstalls_then_reinstalls_sdk_hello_plugin_without_runtime_residue()
- application/src/plugin/mod.rs: refactor FakePackages pour supporter plusieurs staged packages et nettoyer les manifests sur uninstall
- Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-01 19:11:54 +02:00
0061685b08 fix(frontend,plugins): évite le crash sur install/uninstall/reinstall par rechargement systématique de la liste (#120)
- usePlugins.ts: remplace les mises à jour optimistes du state par des appels listPlugins() après chaque opération backend
- PluginsPanel.tsx: ajoute la normalisation isInstallable() pour éviter les crashes si installable est undefined
- Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-01 19:10:44 +02:00
fd2ab4a0d7 merge feature/ticket120-plugin-asset-cors-headers dans develop (#120: headers CORS idea-plugin:// — QA PASS avec reserve e2e AppImage)
Cause racine de la 4e rechute #120 corrigee : plugin_asset_response
posait aucun header CORS, bloquant l'import() dynamique du bundle plugin
sous WebKitGTK. Valide via cargo test -p app-tauri (test CORS cible +
plugin_install_load) et tests frontend runtime/plugins, tous verts.

Reserve QA non levee : pas de preuve visuelle e2e dans un AppImage reel
(fuse absent dans cet environnement) que le bandeau disparait apres
redemarrage. Cloture definitive du ticket #120 a conditionner a cette
validation AppImage reelle.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-01 17:58:46 +02:00
fbe69de0c2 fix(plugins): ajoute les headers CORS sur le protocole idea-plugin:// (#120)
plugin_asset_response ne posait aucun header Access-Control-Allow-Origin,
ce qui bloquait l'import() dynamique du bundle plugin (origine distincte
du document) sous WebKitGTK — cause racine confirmee de la 4e rechute #120
(bandeau « Cross-origin script load denied »). Ajoute Access-Control-Allow-
Origin/-Methods sur toutes les reponses du protocole (succes et erreurs) et
un test backend dedie pour eviter une rechute silencieuse.

QA 2026-08-01 : PASS avec reserve — cargo test -p app-tauri (test CORS
cible + plugin_install_load) et tests frontend runtime/plugins verts,
mais pas de preuve visuelle e2e AppImage dans cet environnement (fuse
absent, AppImage non montable ici). Validation AppImage reelle a faire
avant cloture definitive du ticket #120.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-01 17:58:35 +02:00
95066d4110 merge feature/ticket120-plugin-menu-crash-isolation dans develop (#120: isolation menus plugin validee QA + requalification deploiement)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-01 16:54:36 +02:00
add61f176d chore(tickets): consigne la rechute #120 (requalification deploiement) et enregistre #122
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-01 16:54:33 +02:00
5a30ec8b9c fix(plugins): isole les menus plugin et durcit hello-plugin SDK contre la rechute #120
Requalification Architect du 2026-08-01: le crash INTERFACE INTERROMPUE au
chargement d'un plugin (menu + item) remonte via ProjectsView -> usePluginMenus
-> MenuBar jusqu'à RootErrorBoundary, quel que soit le plugin (ancien ou
reconstruit via SDK).

- usePluginMenus isole la résolution/conversion des contributions plugin :
  toute erreur retombe sur [] au lieu de propager.
- ProjectsView sépare les menus natifs des menus enrichis par plugin et rend
  MenuBar derrière une error boundary locale (fallback menus natifs seuls).
- hello-plugin (SDK) et les tests d'installation associés durcis en cohérence.

Bookkeeping ticket #120 uniquement (issue.md, carnet.md) ; les fichiers
counter.json/index.json et le dossier tickets/122/ restent hors commit car
une collision de numérotation #122 existe entre cette base et
feature/ticket120-hello-plugin-install-path-audit (deux tickets différents
revendiquent #122) — à arbitrer avant de committer le bookkeeping global.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-01 16:23:56 +02:00
8031d86deb merge feature/ticket120-hello-plugin-blackscreen-crash-diagnostics dans develop (#120: diagnostics crash minimales backend + garde-fous frontend contre l'écran noir) 2026-08-01 09:48:59 +02:00
3fc15fd706 chore(memoire): consigne la récidive écran noir hello-plugin (#120)
Trois correctifs déjà mergés sur le même symptôme sans que #120 se ferme ;
note de mémoire projet pour que le prochain agent ne reparte pas d'un
patch symptomatique de plus sans avoir lu l'historique des tentatives.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-01 09:48:55 +02:00
c19fb6bf8c fix(frontend): écran noir plutôt que muet sur crash de plugin ou d'activation figée
Complète le diagnostic backend (#120) côté frontend : un crash React non
capturé (ex. plugin cassant le rendu) laissait un écran noir sans trace, et
une activation de plugin qui ne se résout jamais (promesse infinie) bloquait
le chargement sans échouer. Ajoute RootErrorBoundary + logging d'erreurs
globales autour de l'arbre React, et un timeout sur l'import/l'activation de
chaque plugin dans loadPlugins pour transformer un hang silencieux en échec
explicite et diagnosticable.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-01 09:48:49 +02:00
961bf4623f fix(plugins): diagnostics crash minimales pour l'install de plugin (backend)
Écran noir hello-plugin (#120) récidivant après 3 fixes déjà mergés sans
capturer la cause réelle : on ne pouvait pas savoir si le crash venait de
l'install, du reconcile MCP ou d'un panic silencieux. Ajoute un panic hook
qui logge thread/location/backtrace, trace les étapes install/reconcile/
asset-protocol dans idea.log, et remplace les `.expect()` du superviseur MCP
plugin par une erreur typée au lieu d'un panic sur mutex empoisonné.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-01 09:48:42 +02:00
07df50f9de merge feature/ticket119-skills-agent-capabilities dans develop (#119: capacités agent découvrables via idea_list_agents)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-01 00:27:13 +02:00
0eea4421f9 merge feature/ticket113-llamacpp-args-spaces dans develop (#113: espaces autorisés dans les arguments supplémentaires llama.cpp)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-01 00:27:11 +02:00
e741f76cab merge feature/ticket120-hello-plugin-blackscreen-reinvestigation dans develop (#120: isolation plugin invalide + réconciliation MCP durcie + loader export default/cleanup)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-01 00:27:08 +02:00
e21db9bf40 chore(tickets): met à jour l'état runtime du ticket #119
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-01 00:27:00 +02:00
92b17e9a69 feat(skills): capacités agent découvrables via idea_list_agents
Ajoute SkillKind (Workflow/Reference) sur Skill, extrait le use case
ResolveAgentCapabilities à partir des SkillRef assignés, et enrichit
idea_list_agents d'un champ additif capabilities (name, description,
kind) — remplace l'exposition de SkillRef opaques par un inventaire de
capacités interrogeable, source commune avec le bloc « Skills
disponibles » injecté au lancement (#119).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-01 00:26:56 +02:00
dbaf6fe2f4 fix(model-servers): autorise les espaces dans le champ Arguments supplémentaires llama.cpp
Le champ contrôlé de ModelServersPanel/FirstRunWizard perdait les
espaces saisis dans les arguments llama.cpp (trim/split prématuré sur
chaque frappe au lieu de la seule sérialisation finale) (#113).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-01 00:12:07 +02:00
46086af026 fix(plugins): support export default { activate }, cleanup partiel et erreurs visibles
Le loader accepte désormais aussi la forme export default { activate }
en plus de l'export nommé, les subscriptions partiellement établies
sont nettoyées en cas d'échec d'activation, et une erreur de
runtime-catalog est remontée visuellement dans PluginsPanel avec un
badge Invalide/Isolé sur les plugins concernés (#116/#120).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-01 00:05:57 +02:00
50b71f4ece fix(plugins): isole les plugins non servables et durcit la réconciliation MCP
Un bundle_url invalide ou un plugin dont l'asset n'est pas réellement
servable passe désormais en état Invalid isolé au lieu de faire
échouer globalement la réconciliation MCP au démarrage — cause racine
de la perte d'affichage à l'installation de hello-plugin (#116/#120).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-01 00:05:53 +02:00
ac659c42f2 fix(plugins): renforce le typage des Set filtrés dans loader.ts
Point de départ de la réinvestigation #120 : commandIdsFromContributes
et layoutTypesFromContributes typaient implicitement leurs Set en
unknown, masquant les valeurs vides potentielles issues des
contributions de plugin (piste du crash d'affichage à l'installation).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-31 23:52:42 +02:00
5efb026a80 chore(tickets): synchronise l'état runtime des tickets et de la mémoire
Clôture #114/#115/#116/#117, suppression #111, ouverture #119/#120/#121,
notes mémoire root-cause #113 et angle d'investigation #120.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-31 23:52:33 +02:00
32c257d2e1 Merge branch 'feature/117-opencode-headless-recovery' into develop 2026-07-31 15:05:14 +02:00
10c0bef5e5 ticket117: synchronie métier idea_ask_agent + corrélation task ↔ rendezvous 2026-07-31 15:04:54 +02:00
f6685aa745 Merge branch 'fix/ticket116-plugin-install-black-screen' into develop 2026-07-31 14:18:33 +02:00
d4e61a86f0 fix(ticket116): isoler crash plugin hello-plugin + erreur explicite UI 2026-07-31 14:17:56 +02:00
e042ced724 Merge branch 'feature/ticket115-ideA-skills-runtime-snapshot' into develop 2026-07-31 13:56:46 +02:00
fbe3c51fd4 ticket115: snapshot runtime skills assignés + durcissement idea_skill_read 2026-07-31 13:56:18 +02:00
fe5fe7cb70 fix(hello-plugin): prévient le crash de l'asset protocol dans le runtime Tauri
- Ajoute block_on_protocol_future() pour éviter l'erreur 'Cannot start a runtime from within a runtime'
- Ajoute test unitaire pour vérifier la compatibilité avec le runtime Tauri
- Ajoute test d'intégration pour le hello-plugin du SDK
2026-07-31 13:17:59 +02:00
f81b385616 merge feature/ticket114-uniform-dropdowns dans develop (#114: uniformisation des droplist dynamiques)
QA vert : 148+8+1032 tests passés, typecheck OK.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-30 12:56:14 +02:00
5be5c5975e chore(tickets): synchronise l'état runtime des tickets et du contexte main
Met à jour l'index/compteur de tickets, les tickets #111/#113/#114 et le
contexte de Main suite au traitement du ticket #114.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-30 12:56:07 +02:00
9b1ced50be feat(ui): uniformise les droplist dynamiques sur le style du picker d'agent
Introduit SmallDropdown comme composant partagé et le fait adopter par
AgentsPanel, ModelServerSelect, OpenCodeModeFields, TemplateEditor et
TicketViewportSelect, pour que toutes les listes déroulantes dynamiques
(agent, modèle, template, viewport) partagent la même apparence que le
sélecteur d'agent de la création de ticket.

Refs #114

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-30 12:55:57 +02:00
fda4126a5f merge fix/terminal-fit-remount-stability dans develop (fix: détection de stabilité réelle du fit terminal au remount)
QA: verdict VERT (suite automatisée), réserve manuelle : vérification desktop/Tauri (comportement réel du fit terminal dans l'app packagée) non exécutée.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-30 09:36:10 +02:00
6165eaf8d9 fix(terminals): détecte la stabilité réelle du fit terminal au remount
L'ancien correctif (traîne de refits à nombre de frames fixe,
MOUNT_SETTLE_REFIT_FRAMES) restait insuffisant : une cellule CLI pouvait
rester mal dimensionnée après un changement de projet/layout si l'agent
écrivait en arrière-plan pendant la fenêtre de stabilisation, nécessitant
un resize manuel pour corriger l'affichage. TerminalView détecte
désormais la stabilité réelle du fit (dimensions inchangées sur des
mesures successives) au lieu de s'appuyer sur un nombre de frames fixe
avant de rendre la main au ResizeObserver.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-30 09:36:05 +02:00
c100a0317c merge fix/hello-plugin-black-window dans develop (#hello-plugin: isole les contributions plugin en erreur et durcit menus.ts)
QA: verdict VERT (suite automatisée), réserve manuelle : vérification desktop (chargement réel de l'archive dans l'app packagée) non exécutée.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-30 09:08:25 +02:00
aa850374ce fix(plugins): isole les contributions plugin en erreur et durcit menus.ts
Le chargement de l'archive hello-plugin (build/hello-plugin-0.1.0.zip)
vidait la fenêtre principale : une contribution plugin fautive
remontait jusqu'au rendu global au lieu de rester locale à la cellule.
Ajoute un boundary local dans PluginLayoutCellView/PluginLayoutSelectorSection
et durcit menus.ts/loader.ts/registry.ts contre les entrées de menu ou
contributions malformées.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-30 09:08:14 +02:00
eec3e0a5bc merge feature/codex-mcp-code-mode-direct-tools dans develop (#108: Code Mode Codex restreint au namespace MCP IdeA + initialize.instructions)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-29 22:51:49 +02:00
d0b65a92bd fix(#108): restreint Code Mode Codex au namespace MCP IdeA et documente les tools au démarrage
Codex Code Mode pouvait appeler n'importe quel outil MCP directement,
contournant la médiation d'approbation. On force
[features.code_mode].direct_only_tool_namespaces = ["mcp__idea"] sur
chaque surface qui écrit le config.toml Codex (permission projector,
lifecycle, migration run-dir, assistant de ticket), et on ajoute
initialize.instructions côté serveur MCP pour orienter Codex vers le
bon outil idea_* dès la connexion, sans dépendre de la recherche
sémantique différée.

QA : domain 283/0, application 126/0 + agent_lifecycle 73/0 +
change_agent_profile 19/0 + ticket_assistant 5/0, infrastructure 339/0
dont mcp_server 37/0, backend 68/0 (7 ignored). Les échecs web-server
observés sur cargo test --workspace (Too many open files, cookies)
sont une contamination de ressources inter-tests ; les deux tests
concernés repassent isolément.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-29 22:51:38 +02:00
af6b76935c fix(#108): expose les tools MCP autorisées dès le démarrage de session Codex 2026-07-29 18:19:38 +02:00
2c3a46e690 fix(#105): corrige le contexte plugin pour hello-plugin
Ajoute logger, subscriptions et commandes scindées au contexte plugin
activé. Les plugins full-trust s'attendent à ce shape public.
2026-07-29 17:59:14 +02:00
3f27eb878b merge feature/ticket112-bulk-sprint-assign dans develop (#112: assignation de sprint en masse via multi-sélection)
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-29 15:58:12 +02:00
f5007fcb11 feat(tickets): assignation de sprint en masse via multi-sélection
Permet de sélectionner plusieurs tickets dans TicketsPanel et de leur
assigner un sprint en une seule action, au lieu d'un ticket à la fois.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-29 15:58:04 +02:00
6bd5e64dd1 merge feature/mcp-tool-permissions-sync dans develop (#82: sync permissions MCP <-> tools exposés)
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-29 15:57:53 +02:00
21a84ab8f2 feat(mcp): synchronise les permissions MCP avec les tools réellement exposés
Les permissions déclarées ne reflétaient pas toujours les tools
effectivement exposés aux agents (contexte requester/projet lié après
coup). Ajoute ToolInvoker::tools_for_bound_context/tools_for_context
pour exposer la liste effective au moment de l'injection dans une
requête OpenAI-compatible, et propage le calcul dans la policy MCP,
le serveur, la factory de session et l'adapter openai_compat.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-29 15:57:45 +02:00
5955ea37a2 chore(tickets): synchronise l'état ticketing courant
Met à jour les carnets/issues existants et ajoute les tickets #108,
#109, #111, #112 créés durant le cycle. État runtime sans rapport
avec le lot de code #82, isolé dans son propre commit.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-29 15:57:37 +02:00
30c8009a96 merge fix/tickets-createdby-legacy-normalization dans develop (fenêtre tickets noircissant sur createdBy legacy)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-29 14:19:54 +02:00
712b19ed10 fix(tickets): normalise createdBy manquant sur les payloads legacy
Les tickets legacy sans champ createdBy faisaient noircir la fenêtre
tickets côté frontend. Les adapters (ticket.ts, streamGateways.ts)
normalisent désormais ce champ absent, avec couverture de test dédiée.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-29 14:19:50 +02:00
73a676a002 merge fix/ticket-list-legacy-payload-normalization dans develop (fenêtre liste tickets noircissant sur payload legacy)
QA vert : npx vitest run src/adapters/ticket.test.ts, 6/6 sur 4280c70.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-29 13:52:04 +02:00
4280c70514 fix(tickets): normalise assignedAgentIds/links/attachments manquants sur les payloads legacy
Les lignes de ticket persistées avant l'introduction de ces champs peuvent
arriver sans assignedAgentIds (ni links/attachments), ce que TicketsPanel
déréférence sans garde côté rendu : la fenêtre de liste rend quelques lignes
puis devient noire dès qu'une ligne legacy est itérée. Les deux gateways
(Tauri et HTTP/stream) normalisent désormais chaque ticket et chaque item de
liste avant de les retourner à l'UI.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-29 13:51:13 +02:00
25e1231a9e merge feature/ticket108-web-server-app-tauri-attachment-tests dans develop (lève la réserve QA #108: tests attachments web-server/app-tauri)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-29 11:17:11 +02:00
b55d12d035 test(tickets): renforce la couverture attachments web-server/app-tauri (#108)
Levée de la réserve QA sur #108 : aucun test ciblé ne matchait réellement
sur web-server et app-tauri malgré le câblage attachments tickets.

- web-server: test fonctionnel via /api/invoke pour ticket_create,
  ticket_attachment_add, ticket_attachment_read,
  ticket_attachment_mark_summarized.
- app-tauri: test fonctionnel via la surface publique tool/provider pour
  idea_ticket_create, idea_ticket_attachment_add,
  idea_ticket_attachment_read, idea_ticket_attachment_mark_summarized.

Pas de changement de wiring produit ; assertions alignées sur le contrat
public réel (contentBase64 sans padding =, summarizedBy.kind = user côté
app-tauri).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-29 11:17:05 +02:00
66f0dca916 merge feature/ticket108-attachments dans develop (pièces jointes sur tickets, #108)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-29 11:08:50 +02:00
8158057b1d feat(tickets): ajoute les pièces jointes sur tickets (#108)
Stockage flat côté ticket + métadonnées d'attachments, lecture exposée côté
backend/MCP, et UI minimale de liste/ajout dans TicketDetail. Traverse le
domaine (Issue, ports), l'application (usecases + assistant de ticket), les
adaptateurs infra/MCP (issues store, orchestrateur), les DTO backend/web-
server/app-tauri, et le frontend (domain/ports/adapters/hooks/UI).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-29 11:08:45 +02:00
2692b9cc03 merge feature/ticket109-creator-display-and-filter dans develop (créateur affiché + filtre tickets, #109)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-29 10:46:04 +02:00
9d6d0fbdf1 feat(tickets): affiche le créateur d'un ticket et filtre la liste par créateur
createdBy était déjà présent dans le frontmatter des tickets mais ni exposé
ni exploitable côté UI. Ajout du DTO (domain/ports/mock), affichage dans
TicketDetail, colonne/filtre créateur dans TicketsPanel, et persistance du
filtre. ticketActor.ts introduit pour porter la logique de filtrage côté
frontend, sans changement backend nécessaire (lot frontend pur).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-29 10:45:58 +02:00
d965970696 merge feature/hello-plugin-manifest-fix-and-fixture-tests dans develop (fix manifeste hello-plugin + base de tests fonctionnels plugins)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-29 10:01:04 +02:00
6270f98e54 fix(plugin-sdk): aligne le manifeste hello-plugin sur le schéma backend + fixture de test
Le manifeste hello-plugin était généré par un SDK obsolète/désaligné avec le
schéma backend actuel (champ ideaPluginManifestVersion manquant, displayName,
trustLevel, shape de contributes), ce qui faisait échouer l'installation avec
« invalid input: missing field ideaPluginManifestVersion ».

- SDK (manifest.ts/js, index.ts) aligné sur le schéma backend courant.
- hello-plugin (exemple + fixture) régénéré avec le manifeste valide.
- Base de tests fonctionnels plugins : fixture réelle versionnée
  (reference-minimal) + test d'installation/chargement bout en bout
  (plugin_install_load.rs), pour couvrir install/load/catalog depuis un
  dossier fixture réel.

Le sous-repo git imbriqué et vide (sdk/IdeaSDK/.git, 0 commit) a été
neutralisé pour que les sources du SDK soient suivies normalement dans ce
dépôt plutôt que comme gitlink vide.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-29 10:00:58 +02:00
c1ff98086c merge feature/frontend-mcp-panel-terminal-refit-fixes dans develop (panneau permissions idea_ask_agents + fit terminal au remount projet)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-28 22:51:53 +02:00
f0ba559885 fix(frontend): expose idea_ask_agents et renforce le fit terminal au remount projet
Panneau Permissions: idea_ask_agents est câblé côté backend MCP mais absent
du groupe « Délégation agents » du panneau — ajout de l'outil et de son
label, catalogue mock MCP aligné en conséquence.

Terminaux: ProjectsView remonte LayoutGrid via une key au changement de
projet, donc refitEpoch n'aide pas ; le montage de TerminalView ne
maintenait pas assez longtemps le fit tant que la nouvelle cellule ne
s'était pas stabilisée. Le chemin de montage garde désormais une traîne de
refits plus longue (MOUNT_SETTLE_REFIT_FRAMES) avant de laisser la main au
ResizeObserver.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-28 22:51:48 +02:00
b4f4c8eb71 merge feature/floatingwindow-zindex-dropdown-fix dans develop (fix z-index TicketViewportSelect)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-28 22:37:46 +02:00
ec305657ad fix(tickets): TicketViewportSelect passe au-dessus des FloatingWindow
Le popup viewport-positionné utilisait zIndex.menuDropdown (40), inférieur à
zIndex.floatingWindow (50) : il s'affichait derrière une fenêtre flottante
ouverte. Ajout de zIndex.transientPopup (65), au-dessus de floatingWindow et
floatingWindowNested, pour tout popup transitoire porté par document.body
depuis une FloatingWindow.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-28 22:37:36 +02:00
6fa41013ed bulk operations test coverage
- tickets_missing_carnet: backend test coverage
- ticket.test.ts: frontend adapter test coverage
2026-07-28 20:41:46 +02:00
bd4f76ae74 bulk operations fixes
- Frontend: implémente bulkDelete, bulkArchive, bulkRestore
- Backend: adapts ticket DTOs pour bulk operations
- Infrastructure: MCP server pour gestion bulk tickets
- Tests: coverage frontend + backend
2026-07-28 20:38:07 +02:00
73c6081ab8 restore .ideai/tickets/ + corrig .gitignore
- Enlève les ignore rules .ideai/tickets/ dans .gitignore
- Permet le suivi durable du store tickets futur
- Ne touche pas sdk/ (reste untracked)
2026-07-28 20:19:55 +02:00
e1b1c1e103 restore .ideai/tickets/ store versionnέ + corrige .gitignore
- Restaure .ideai/tickets/ depuis 851f1f8^ (167 tickets + index.json + counter.json)
- Enlève les ignore rules .ideai/tickets/ dans .gitignore (ligne 51 et 75)
- Permet le suivi durable du store tickets futur
- Ne touche pas sdk/ (reste untracked)
2026-07-28 20:18:00 +02:00
f0a63de042 fix(#100 #101): corrige plugin_review_package et opencode_model_server_block
- #100: plugin_review_package prend ReviewPluginPackageDto valide (source_kind)
- #101: opencode_model_server_block débloque modèle quand pas utilisé
- Tests verts: plugin.test.ts + model_server.rs
2026-07-28 20:02:30 +02:00
9b150983bb fix(ticket #7): ajoute le bouton Annuler aux notifications de fin de background task 2026-07-28 19:34:52 +02:00
f4ae5df17c fix(BulkDeleteIssues): implémente retour BatchIssueResult sans issue (#7) 2026-07-28 19:30:16 +02:00
bcd489aac8 merge feature/4-cellgrid-refresh-on-layout-change dans develop (LayoutGrid refitEpoch) 2026-07-28 19:15:12 +02:00
5d6a295715 feat(layout): refitEpoch test + implementation LayoutGrid 2026-07-28 19:09:07 +02:00
50219df4e5 merge feature/3-tickets-dropdown-viewport-clip dans develop
Ticket #3 vert (995/995 suite complète, tsc propre) : les dropdowns de la
vue Tickets ne sont plus rognées en bas de fenêtre.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-28 18:29:47 +02:00
05402c7544 fix(tickets): dropdowns ne sortent plus du viewport en bas d'écran (#3)
Remplace les <select> natifs de la vue Tickets (statut, priorité, tri,
lien, agent assigné/assistant, sprint) par TicketViewportSelect, qui
repositionne intelligemment son overlay selon l'espace disponible dans
la fenêtre au lieu de toujours ouvrir vers le bas.

QA vert : 80/80 (frontend/src/features/tickets), tsc --noEmit propre.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-28 18:29:17 +02:00
6da52c6a02 wip(tickets): backend createdBy (#5) + bulk status/priority/delete (#6)
Ajoute created_by sur IssueIndexEntry/TicketSummaryDto + filtre createdBy
(#5), et les use cases BulkUpdateIssueStatus/Priority + BulkDeleteIssues
avec les DTO/outils MCP idea_ticket_bulk_* associés (#6).

NON VERT : BulkDeleteIssues::execute référence BatchIssueResult::deleted(),
constructeur pas encore ajouté à BatchIssueResult (seuls ok/err existent) ->
`cargo check` échoue (E0599 dans application::issues::mod). Reste à
DevBackend avant toute QA/merge.

Branché sur feature/sdk-integration (dépend du commit #2 dans
orchestrator/mcp/server.rs et tools.rs) ; à rebaser sur develop une fois
feature/sdk-integration mergé.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-28 18:28:39 +02:00
1ef1fd9e40 feat(mcp): ajoute l'outil idea_ask_agents pour la délégation parallèle (#2)
Wrapper MCP backend pur : dispatche N requêtes idea_ask_agent en parallèle
et retourne un résultat par requête, dans l'ordre, en rejetant les cibles
dupliquées avant dispatch. Aucun changement de domaine/application — pose
la primitive nécessaire au SDK (chantier feature/sdk-integration).

QA vert (ticket #2).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-28 16:56:22 +02:00
454f8ad57d merge feature/117-opencode-headless-recovery dans develop
Feature terminée et verte (Architect/DevBackend/DevFrontend/QA au vert) :
durcissement de la reprise headless inter-projets et persistance des
profils Opencode.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-28 14:13:04 +02:00
045e0984cc chantier: durcissement reprise headless inter-projets + persistance profils Opencode
- Implémentation reprise de session Opencode headless (conversational_recovery)
- Persistance des profils IA Opencode dans .ideai/memory avec JSON Schema
- Gestion des permissions MCP pour agents externes
- Tests QA verts : structured_launch_d3, conversation_log, tickets_missing_carnet, agents, ProfilesSettings
2026-07-28 12:23:34 +02:00
78f7c8fe2d merge develop into feature/85-fix-flaky-setcellagent-test 2026-07-27 17:24:40 +02:00
851f1f8f2c chore(gitignore): stop tracking local IdeA tickets state 2026-07-27 17:23:19 +02:00
41aa2789a7 merge feature/fix-opencode-final-capture dans develop 2026-07-27 17:15:51 +02:00
f4895208d7 merge feature/91-rendezvous-toast-label dans develop
Ticket #91 — libellé explicite « Appel X -> Y terminé/en échec/annulé »
pour les notifications de fin de background task issues d'un rendez-vous
inter-agent. Frontend pur, tests annoncés verts.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-27 16:49:26 +02:00
88a5256a1e feat(rendezvous): libellé explicite des notifications de fin de background task (#91)
Le toast de fin de tâche de fond liée à un rendez-vous inter-agent passe
de « Main -> DevBackend completed » à « Appel Main -> DevBackend terminé »
(idem en échec / annulé), pour nommer explicitement l'appel plutôt qu'un
état brut. Fallback générique conservé quand requester/target sont absents.

Validations obtenues avant commit : tests frontend annoncés verts pour #91.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-27 16:49:22 +02:00
efbd084b7d merge feature/58-background-task-live-subscriber dans develop
Ticket #58 — rendu live des tâches de fond (subscriber UI + canal IPC
attachable au task output). Validations vertes : tests infrastructure,
cargo check backend/app-tauri, vitest workstate, typecheck, QA.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-27 16:48:33 +02:00
b734c237d3 feat(background-task): rendu live des tâches de fond — subscriber UI + canal IPC (#58)
Câble un canal attachable au flux de sortie d'une tâche de fond (runner
infrastructure + commande app-tauri + port/adaptateurs frontend) et le
panneau ProjectWorkStatePanel s'y abonne pour un rendu live au lieu d'un
état figé au dernier snapshot.

Validations obtenues avant commit :
- cargo test -p infrastructure --test background_task_runner : vert
- cargo check -p backend -p app-tauri : vert
- npx vitest run src/features/workstate/workstate.test.tsx : vert
- npm run typecheck : vert
- verdict QA #58 : vert

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-27 16:48:29 +02:00
e1d8f5885f fix(opencode): capture Final trop stricte et ordre parse/status
Un tour OpenCode sans texte mais terminé proprement (step_finish, ex.
tool-call-only) échouait en Decode alors qu'aucune erreur réelle ne
s'était produite : parse_jsonl_turn émet désormais un Final vide dans
ce cas au lieu d'un hard-fail, réservé aux flux vraiment vides,
ignorés ou seulement démarrés.

send() inversait aussi l'ordre de décision : un statut de sortie non
nul faisait échouer la délégation même quand stdout contenait un
événement terminal structuré exploitable (Final/Error). Le parse est
maintenant tenté avant l'évaluation du statut, et un événement
terminal structuré prévaut sur un exit code non nul.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-27 14:30:03 +02:00
6f532d7434 merge feature/ticket96-effective-permissions-assistants-ticket dans develop 2026-07-27 14:18:59 +02:00
ce375c3e70 merge feature/67-correct-repository-branch dans develop 2026-07-27 14:18:57 +02:00
0b83b5bbd2 feat(lock): implémentation lock inter-process app-data-dir V1 — acquisition non-bloquante avec RAII 2026-07-27 13:57:58 +02:00
e74a9703f9 feat: livrable ticket #96 — effective permissions pour assistants de ticket 2026-07-27 13:37:08 +02:00
865f90eafd merge feature/multi-profiles-codex-clarification-toast-notices dans develop
Résout le conflit d'imports/helpers de tests dans
crates/application/tests/model_server.rs par union des deux côtés
(imports application/domain + helpers aid/nid/sess).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 13:06:35 +02:00
d7b6038f23 merge feature/ticket107-multi-project-isolation dans develop
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 13:04:51 +02:00
cf074a7d61 fix(runtime): isolation d'usage multi-projet #107
Implémentation du garde ModelServerProjectUseGuard pour séparer
les retours des agents entre projets concurrents.

- Garde RAII par LocalModelServerId partagé entre projets
- Refus inter-projets concurrent via model_server_in_use
- Partage intra-projet conservé avec refcount
- Libération automatique à la fermeture/erreur de session

Tests de validation: rejet projet distinct, compteur refs, libération retrait
2026-07-27 09:47:23 +02:00
038e90ecec feat: livrable ticket #91 — notification fin BackgroundTask enrichie
- Backend: enrichissement HeadlessRendezvous avec requester/target/conversationId
- Frontend: toast 'Requester -> Target completed/...' explicite
- Clic ouvrant viewer de conversation pour visualiser l'échange
2026-07-27 09:05:34 +02:00
02603441c1 fix: livrable tickets #70 #100 #102 — UX surface scoping
- #70: implémentation suppression modèles locaux téléchargés
- #100: correction scroll OpenCode
- #102: correction fit TUI après switch/layout
- memory note scoping UX
2026-07-26 19:42:06 +02:00
4321d048ac fix: correction de régression UI wizard first-run 2026-07-26 16:52:23 +02:00
ca70ec75f4 feat: catalogue dynamique modèles Codex/Claude avec compatibilité CLI locale
Ajout du catalogue enrichi pour les modèles Codex et Claude avec:
- Compatibilité estimée avec la version CLI locale détectée
- Source d'origine (catalogue/Provider) pour chaque entrée
- Support du catalogue Provider API externe
- Matrice de compatibilité embarquée dans l'application

Frontend:
- UI de configuration des modèles avec affichage des états de compatibilité
- Suggestions dynamiques avec badges de compatibilité
- Messages d'aide contextuels (compatible/unknown/likelyTooRecent)
- Alertes non-bloquantes pour les modèles trop récents
- Gestion des échecs de catalogue avec saisie manuelle conservée

Backend:
- Ports CliVersionReader, ProviderModelCatalogue, CompatibilityMatrixSource
- Implémentations: ProcessCliVersionReader, HttpProviderModelCatalogue, EmbeddedCompatibilityMatrix
- Enrichissement des DTOs avec compatibility, cli_version, warnings
- Tests unitaires complets pour le resolver de catalogue
2026-07-26 16:09:10 +02:00
e7bf1d3666 frontend: suppress network banner params unneeded after runtime lock refactor 2026-07-26 15:12:14 +02:00
e5bafc30e7 Merge branch 'main' into feature/multi-profiles-codex-claude-model-catalogue 2026-07-26 14:57:31 +02:00
ea7ea71230 feat: finalise multi-profil Codex/Claude avec catalogue de modèles
- Backend : clone_profile_from_seed généralisé (non OpenCode)
- Backend : catalogue static Claude/Codex (3 modèles chacun, 1 recommandé)
- Backend : commandes Tauri list_claude_models/list_codex_models
- Frontend : ProfilesSettings refonte en onglets Codex/Claude + create/duplicate/edit/delete
- Frontend : ModelSelect searchable partagé + fallback saisie manuelle
- Frontend : assignation agent nom · modèle
- Tests QA : 4 profils modèles distincts (2 Claude, 2 Codex) assignés à agents
2026-07-26 14:56:26 +02:00
c807a70fea Remove all target/ files from index (should be .gitignore'd) 2026-07-26 14:22:52 +02:00
d741035c47 Remove tracked files from target/release/bundle/appimage after AppImage rebuild
- Remove app-tauri binary (should be in source, not target)
2026-07-26 14:21:17 +02:00
455eba3f91 Fix git index: remove target/artefact .gitignore, keep runtime JSON in index 2026-07-26 14:16:45 +02:00
13ff1a4f51 ignore .ideai/background-tasks/ (runtime tasks sensibles, issue b8-arbitration-outcomes) 2026-07-26 14:15:26 +02:00
480cdc41ac ignore .ideai/background-tasks/ (runtime tasks sensibles) 2026-07-26 14:14:50 +02:00
0821739924 feat: finalise ticket99 - implémentation agent model configuration v2
- agent/lifecycle.rs: lifecycle management per profile
- agent/provider_catalogue.rs: provider registration with model support
- agent/usecases.rs: usecases for profile-based agent invocation
- agent/mod.rs: expose agent capabilities via AgentManager
- backend/dto.rs: AgentModelConfig, AgentProviderConfig DTOs
- domain/profile.rs: extend Profile avec agent capabilities
- domain/permission.rs: permission checks pour agent access
- infrastructure/assistant/mod.rs: agent integration
- infrastructure/permission/{claude,codex}.rs: permission handlers
- web-server/lib.rs: agent endpoints
- commands.rs: agent commands
- frontend/adapters/{http,profile,mock,domain}.ts: adapters
- frontend/first-run/FirstRunWizard.{test.tsx,tsx}: first-run flow
2026-07-26 13:38:18 +02:00
b5d7e16501 feat: correction provider/API key - removal Codex/Claude provider configs 2026-07-26 13:23:04 +02:00
dae07d35bb feat: implémentation et QA ticket99 - agent model configuration v2
- backend A-C: VO Codex/Claude, renderers/projecteurs modèle, SecretRef/env, catalogues/use cases/Tauri commands
- frontend D: profils Codex/Claude provider->model->secret, validations, conservation SecretRef
- fix: app-tauri embedded_server isolant IDEA_WEB_ROOT

QA: backend 57/57 tests, frontend 74/74 tests OK
2026-07-26 11:56:25 +02:00
13fb538880 fix(permissions): validate network access flow 2026-07-26 10:52:46 +02:00
3047dc9195 feat(permissions): expose network permission state (#103) 2026-07-25 23:06:50 +02:00
e8731834f4 merge: integrate ticket 101 multi-project isolation 2026-07-25 22:14:19 +02:00
6e98fd89f7 fix(runtime): isolate agent state by project (#101) 2026-07-25 22:14:02 +02:00
da907b880e Fix terminal resize bug
Fix resize handling in TerminalView component and update related tests
2026-07-25 14:54:57 +02:00
6a87c4635f merge: integrate ticket 98 OpenCode provider fix 2026-07-25 14:27:10 +02:00
ad491e765f fix(opencode): make models.dev providers cache-independent 2026-07-25 14:26:15 +02:00
69e5878679 fix(backend): clone du seed OpenCode tolère un seed persisté converti en cloud
CloneOpenCodeProfileFromSeed::execute rejetait auparavant tout profil persisté squattant l'UUID déterministe du seed canonique opencode-llamacpp avec « internal error: canonical OpenCode seed is not an OpenCode profile ».

Root cause: un profil persisté converti en backend cloud GLM5.2 (ticket #92, opencodeProvider) conserve l'UUID du seed ; le find le matchait et le garde-fou seed.opencode.is_none() — non mis à jour pour le backend cloud — déclenchait une erreur Internal bloquante.

Correctif:

- Le find exige désormais un seed OpenCode valide (structured_adapter OpenCode + au moins un backend opencode local OU opencode_provider cloud), et retombe sur le seed catalogue sinon au lieu d'errer sur un état de store inattendu.

- L'override opencode local remet opencode_provider = None pour honorer l'invariant #97 opencode_backend_is_consistent (miroir de AgentProfile::with_opencode).

- 2 tests de régression (fallback catalogue, seed cloud accepté) + 1 test de symétrie save ajoutés.

Vérification: cargo test -p application --test profile_usecases -> 25 passed.
2026-07-25 01:47:58 +02:00
55330732dd Merge feature/ticket97-opencode-provider-mutual-exclusion into develop 2026-07-24 19:52:49 +02:00
0f0a76d806 fix(backend): exclusion mutuelle des backends OpenCode (llamacpp vs cloud) (#97)
Les builders `with_opencode` / `with_opencode_provider` s'évacuent
réciproquement (dernier appel gagnant) pour honorer l'invariant
`opencode_backend_is_consistent`. Le use case SaveOpenCodeProviderProfile
route désormais via le builder au lieu de muter le champ directement — c'est
ce qui dupliquait `opencode` + `opencodeProvider` et forçait un repli sur
llamacpp même quand l'utilisateur choisissait un provider cloud.

Défense en profondeur côté store :
- `read_doc` répare les profils corrompus sur disque (drop du stale `opencode`)
- `save` refuse de persister un profil violant l'invariant via le nouveau
  variant `StoreError::Invalid` (mappé vers `AppError::Invalid`)

Tests verts : builders last-wins (domain), save rejets + read repair
(infra, profile_store 10/10).

Refs #97
2026-07-24 19:52:34 +02:00
7fee56acf5 Merge feature/ticket95-opencode-mcp-timeout into develop 2026-07-24 15:18:13 +02:00
6e9a3ff657 fix(agent): timeout MCP OpenCode aligné sur le plafond du rendez-vous (#95)
Le timeout hardcoded 15000ms (15s) dans le bloc mcp.idea de l'opencode.json
généré par IdeA était far too short pour idea_ask_agent, qui bloque pendant
que l'agent cible travaille. OpenCode tuait la requête à 15s avec l'erreur
-32001 « Request timed out », même si la cible répondait correctement
(visible dans le workstate). Claude/Codex n'étaient pas affectés car leur
config MCP n'a pas de champ timeout.

Désormais le timeout est résolu par resolve_opencode_mcp_timeout_ms() :
- défaut 4h (14_400_000 ms), aligné sur DEFAULT_RENDEZVOUS_CEILING ;
- overridable via IDEA_OPENCODE_MCP_TIMEOUT_MS ;
- fallback sûr sur 0/parse-error (jamais d'expiration instantanée).

Les 4 occurrences (lifecycle.rs x2 + assistant/mod.rs x2) utilisent la même
fonction exportée depuis application::agent. Aucune modification des configs
MCP Claude/Codex.
2026-07-24 15:00:53 +02:00
7d3e74a114 Merge feature/opencode-permissions-projection into develop
Fix backend isolé, tests unitaires verts (ticket #94).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-23 18:14:27 +02:00
56631bd3c8 fix(backend): projeter les EffectivePermissions dans le bloc permission d'opencode.json
Les 4 générateurs opencode.json/opencode_provider.json codaient en dur
{"bash":"ask","edit":"ask"}, ignorant les permissions configurées côté
IdeA pour l'agent. Claude et Codex appliquaient déjà PermissionProjector,
seul OpenCode passait à côté.

Ajoute domain::opencode_permission_block(eff: Option<&EffectivePermissions>)
qui mappe bash ← posture bash effective, edit ← posture Write effective
(Read/Delete non exprimables dans le schéma OpenCode, déjà enforcées par
le sandbox Landlock). eff == None omet la clé permission entièrement,
préservant le prompting natif OpenCode — même invariant que Claude/Codex.

Câble eff jusqu'aux 4 sites d'appel (lifecycle.rs + assistant/mod.rs,
variantes llamacpp et provider cloud). Le chemin ticket-assistant
(assistant/mod.rs) n'a pas de PermissionStore par agent pour l'instant,
donc eff y reste None (comportement inchangé, pas de régression).

Réf ticket #94.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-23 18:14:20 +02:00
c9fffd7c47 Merge feature/fix-opencode-jsonl-parsing into develop
Fix confiné à l'adaptateur OpenCode (parsing JSONL text.part.text +
gestion événements error), validé par QA (cargo test -p infrastructure
309 passed, 0 failed).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-23 16:23:59 +02:00
0f57e7323a fix(backend): lecture du texte JSONL OpenCode niché sous part.text
Le parseur lisait value.text/value.content à la racine alors que
`opencode run --format json` niche le texte réel sous value.part.text
(cf. packages/opencode/src/cli/cmd/run.ts). Conséquence : idea_ask_agent
vers un profil OpenCode échouait systématiquement avec « OpenCode n'a
produit aucun final textuel » malgré une réponse CLI normale.

Ajoute aussi la gestion des événements type "error" (ParsedEvent::Error,
ReplyEvent::Error) pour distinguer un échec explicite d'un final vide,
et des tests de conformité sur le format JSONL réel confirmé.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-23 16:23:50 +02:00
4ac2dd1568 Merge feature/fix-gguf-shard-selection into develop
Fix backend de sélection GGUF (fichier fusionné prioritaire sur les
shards partiels) — QA vert : cargo test -p infrastructure/application,
cargo check --workspace, 3 nouveaux tests unitaires.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-23 13:23:59 +02:00
557d1c3f24 fix(backend): sélection GGUF prioritaire au fichier fusionné sur les shards
Quand un repo HuggingFace héberge à la fois le fichier GGUF fusionné et
ses shards pour une même quantisation, select_gguf_file (tri alphabétique
naïf) pouvait retenir un shard partiel plutôt que le fichier fusionné ou
l'ensemble complet des shards, causant un échec immédiat au démarrage du
serveur llama.cpp (agent Context).

select_gguf_files renvoie désormais soit le fichier fusionné seul (priorité),
soit tous les shards correspondants triés par index — jamais un shard isolé.
Le téléchargement, le cache et la reprise gèrent le cas multi-fichiers
(manifest de shards, chemins locaux préservant le nom distant pour
l'autoload de llama.cpp).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-23 13:23:55 +02:00
e8f6e9eded Merge feature/ticket92-opencode-provider-dynamic-catalog into develop
Complément post-livraison du ticket #92 : catalogue de providers
OpenCode dynamique (cache ~/.cache/opencode/models.json, repli
statique garanti) + option provider personnalisé en saisie libre.
QA verte : backend cargo build+test workspace, frontend tsc/build,
vitest 958/958.
2026-07-23 12:44:17 +02:00
ef747cd156 chore(ideai): état runtime — permissions et tâche de fond
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-23 12:44:10 +02:00
1784027f5d feat(frontend): provider OpenCode dynamique + saisie provider personnalisé (#92)
Le picker de provider OpenCode du first-run wizard consomme le
catalogue dynamique exposé par le backend et propose une option
« provider personnalisé » avec un formulaire de saisie libre
(id + clé API) quand le provider souhaité n'y figure pas.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-23 12:44:02 +02:00
e943a0efed feat(backend): catalogue de providers OpenCode dynamique + provider personnalisé (#92)
Le catalogue de providers OpenCode lit désormais le cache local
~/.cache/opencode/models.json pour refléter les providers réellement
disponibles, avec repli garanti sur le catalogue statique en cas
d'absence ou d'erreur de lecture du cache. Ajout d'un champ additif
`custom` sur OpenCodeProviderConfig pour permettre à l'utilisateur de
déclarer un provider hors catalogue (id + clé API en saisie libre).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-23 12:43:59 +02:00
162e3ae641 chore(ideai): état runtime — tickets, mémoire, tâches de fond
Ticket #92 rouvert, mises à jour de carnets/tâches de fond.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-23 08:57:15 +02:00
12c7d103d0 Merge feature/ticket92-opencode-provider-cloud into develop
Ticket #92 — support des providers OpenCode cloud, backend + frontend,
QA vert des deux côtés (cargo test workspace + 952 tests frontend).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-23 08:18:09 +02:00
c181b43d04 feat(frontend): support des providers OpenCode cloud (#92)
Ajoute l'UI de configuration des providers OpenCode cloud dans le wizard
first-run (sélection, édition, sauvegarde, suppression), le domaine et
les ports associés, ainsi que les adapters HTTP/mock correspondants.

Build + 952 tests verts, comportements clés vérifiés en exécution réelle,
y compris un test de couverture ajouté pour le parcours d'édition.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-23 08:18:02 +02:00
23a3c2788f feat(backend): support des providers OpenCode cloud (#92)
Ajoute le catalogue statique de providers OpenCode (lot B3), le stockage
sécurisé des secrets (SecretStore + adapter infrastructure), et les
use cases SaveOpenCodeProviderProfile/DeleteProfile câblés en composition
root. Couvre le fix B1 et les tests de régression demandés par QA.

cargo build --workspace propre, cargo test --workspace -- --test-threads=1
intégralement vert.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-23 08:03:03 +02:00
bece7c92c5 Merge feature/ticket43-plugin-system into develop
Système de plugins (#43) : backend (domaine/application/infrastructure,
lots B1-B4) + frontend (runtime, menus, layouts custom, lots F1-F4).
Validé vert par QA (cargo test + npm typecheck/test 947/947).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-22 07:37:28 +02:00
98fb05447d chore(ideai): état runtime — tickets, mémoire, tâches de fond
État d'exécution accumulé (tickets créés/mis à jour hors #43, notes de
mémoire, tâche de fond) capturé au moment du commit de la feature.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-22 07:37:19 +02:00
ac726d075e feat(frontend): système de plugins — runtime, menus, layouts custom (#43)
Lots F1-F4 : runtime de chargement/registre plugin, extension des menus
existants, panneau de gestion des plugins, types de layout custom
(sélecteur, fallback, cellule dédiée) branchés sur le port plugin.
Suite npm typecheck/test verte (947/947).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-22 07:37:11 +02:00
bb35641715 feat(backend): système de plugins — domaine, application, infrastructure (#43)
Lots B1-B4 : modèle de domaine des plugins (manifeste, capacités menus/layouts/MCP),
port et registre applicatif, chargement/validation en infrastructure, exposition DTO
et commandes Tauri. Tests cargo verts.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-22 07:37:03 +02:00
47aacc6da9 Merge feature/ticket61-cells-refit-web-regression into develop
Corrige la régression persistante en version web du refit des
cellules terminal (#61 rouvert) : le rafraîchissement du scaling
CLI après ajout/suppression de cellule ne se déclenchait pas dans
le workspace web, forçant un redimensionnement manuel.

QA : tsc propre, 909/909 tests vitest, aucune régression desktop
(LayoutGrid/useLayout/TerminalView).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-21 21:23:34 +02:00
3a18556ffa fix(frontend): refit web agent cells after opening a new one (#61 web regression)
The web shell never adopted the desktop's #61 fix: WebAgentCell/WebWorkspace
didn't pass any refitSignal to TerminalView, so a cell opened after another
kept a stale xterm scaling — desktop "fixed" it via an incidental window
resize, but mobile has no such escape hatch.

- TerminalView: a refit landing on a transient 0x0 container now reschedules
  on the next few frames instead of giving up for good (bounded retries),
  closing the independent timing gap Architect identified. refitSignal stays
  the single explicit-refit mechanism; the terminal/PTY is never recreated,
  and resize is still pushed to the PTY only when rows/cols actually change.
- WebAgentCell: new optional refitSignal prop, forwarded to TerminalView
  as-is (no key change, no remount).
- WebWorkspace/LiveProjectPanel: new cellLayoutVersion counter, the web
  equivalent of desktop useLayout.layoutVersion, bumped on every cell
  open/close and forwarded as refitSignal to the visible WebAgentCell.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-21 21:21:52 +02:00
a197197a90 Merge feature/ticket89-server-autostart into develop
Ajoute l'option de lancement automatique du serveur web au démarrage
d'IdeA (#89) : déclenchement backend Tauri au boot selon la
préférence utilisateur persistée, réglage frontend dans les
paramètres de déploiement avec erreur port occupé actionnable.

QA : 57 tests backend app-tauri verts (embedded_server/auto_start
compris), 895/895 tests frontend, tsc propre.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-21 21:16:59 +02:00
4fd339c047 Merge feature/ticket90-web-missing-menus into develop
Ajoute les menus Panneaux/Paramètres manquants à la version web
(#90), avec élargissement de l'allowlist /api/invoke côté
web-server pour router les commandes correspondantes.

QA : 895/895 tests frontend, tsc propre, tests backend
web_invoke_routes verts.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-21 21:16:55 +02:00
e9b01795d1 feat(frontend): démarrage auto du serveur + erreur port occupé actionnable (#89)
Étend ServerExposureSettings avec autoStart (défaut false, mock aligné sur le
backend). useDeployment expose setAutoStart, qui persiste immédiatement le
draft sans jamais appeler start() ni toucher le comportement de stop(), et ne
met à jour l'état local qu'après confirmation de la sauvegarde (même piste de
validation que start/save). DeploymentSettings ajoute la case à cocher sous
le panneau Serveur, et des actions « Modifier le port »/« Réessayer » quand le
statut échoue avec le code PORT_IN_USE stabilisé côté backend.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-21 18:38:40 +02:00
30f6415d51 feat(frontend): ajoute les menus Panneaux/Paramètres à la version web (#90)
WebWorkspace gagne un menu « Panneaux » qui route la surface principale du
projet ouvert vers les panneaux transport-neutres déjà réutilisables
(contexte, agents, templates, skills, permissions, mémoire, git) en plus des
surfaces web existantes (travail live, tickets, sprints), ainsi qu'un variant
web du panneau Projets (création par chemin serveur saisi manuellement, sans
browse natif). WebApp gagne un menu « Paramètres » (Profils IA, Appareils,
Déploiement désactivé "Desktop uniquement") qui remplace l'ancien bouton
unique "Appareils".

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-21 18:33:22 +02:00
cb2d0c2d44 feat(app-tauri): option de lancement auto du serveur web au démarrage
Ajoute le déclenchement du serveur embarqué dès le démarrage d'IdeA
selon la préférence utilisateur, sans action manuelle requise.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-21 18:32:03 +02:00
678ff3011b feat(web-server): élargir l'allowlist /api/invoke pour les menus Panneaux
Permet aux commandes Tauri des menus manquants (#90) d'être invoquées
depuis la version web via le proxy /api/invoke.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-21 18:31:58 +02:00
277a0e494a Merge feature/ticket87-web-workspace-collapse-tasks into develop
Repliage par défaut des background tasks par agent dans le WebWorkspace
(#87), fix frontend pur, tests verts (887 passants, tsc clean).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-21 17:56:25 +02:00
1139041603 feat(frontend): repliage par défaut des background tasks par agent (#87)
WebWorkspace replie désormais par défaut la liste des background tasks
par agent dans le panneau Work ; QA a ajouté les cas de test associés
dans WebWorkspaceLive.test.tsx (887 tests verts, tsc --noEmit clean).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-21 17:56:21 +02:00
527c2dde61 Merge feature/ticket86-web-tickets-sprints-ui into develop
Ticket #86, lot 2 : surface tickets/sprints pour le workspace web, avec fix
QA sur le changement/retrait de sprint sur un ticket. QA vert.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-21 07:44:51 +02:00
e7f67bada9 fix(frontend): sprint change/removal on tickets, web workspace (#86 QA fix)
QA-flagged gap: the web surface could only ADD a ticket to a sprint, never
change or clear it, despite the backend already exposing both
ticket_assign_sprint and ticket_unassign_sprint.

- useTicketDetail: new setSprint(sprintId | null) method (additive, also
  available to the desktop TicketDetail — unused there today, no behaviour
  change), routing through the existing TicketGateway.setTicketSprint.
- WebTicketDetail: Sprint selector in "Statut et priorité", immediate save
  like status/priority; empty value clears back to "Sans sprint".
- WebSprintsView: each sprint card now shows its tickets (compact list,
  resolved client-side like the desktop SprintManager) with a "Retirer du
  sprint" action per ticket, calling assignSprint(ref, null) — symmetric
  with "Ajouter tickets". Extracted the card into a SprintCard subcomponent
  to keep the growing card readable.
- Tests: WebTicketsSprints.test.tsx now has 16 tests (was 10) — added
  sprint change/clear, sprint removal from the Sprints tab, agent
  assign/unassign, ticket link/unlink, carnet save, and free-text search
  filtering.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-21 07:43:09 +02:00
e69361feb7 feat(frontend): tickets/sprints surface for the web workspace (#86 lot 2)
Adds a Live/Tickets/Sprints tab navigation to WebWorkspace after a project
is opened — a mobile-first adaptation, not a port of the desktop docks/
floating windows, per carnet #86. The web-server transport (17 ticket_*/
sprint_* commands) and the HttpTicketGateway were already wired (lot 1 +
pre-existing gateway code); this lot is UI only.

- Tickets tab: search/filters, list grouped by sprint, create screen,
  detail view with stacked accordion sections (Résumé/Statut et priorité/
  Carnet open by default; Agents assignés/Liens/Zone dangereuse collapsed),
  delete confirmation, optimistic-concurrency conflict banner.
- Sprints tab: create/rename/reorder (Monter/Descendre)/delete with
  confirmation, add tickets via a mobile full-screen ticket picker (never
  a small desktop modal), "Voir tickets" filters the Tickets tab to one
  sprint.
- Reuses the transport-neutral hooks as-is (useTickets, useTicketDetail,
  useTicketSearch) — only presentation and copy are web-specific, in
  French per decision #78 (new local label module, not a reuse of the
  English desktop ticketMeta labels).
- Workaround: `list_agents` isn't in the web-server allowlist, so agent
  names/assignment options are derived from `get_project_work_state`
  (already used by the Live tab) instead of the desktop's useProjectAgents.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-21 07:35:20 +02:00
45def4844a Merge feature/ticket86-web-tickets-sprints into develop
Ticket #86, lot 1 : commandes tickets/sprints exposées sur le transport web
(web-server), DTO tickets factorisés entre Tauri et web (ticket_dto.rs).
QA vert. Le lot 2 (frontend) suit sur une nouvelle branche.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-21 07:20:46 +02:00
5a7431b442 feat(backend): commandes web tickets/sprints + factorisation DTO (#86 lot 1)
Expose les commandes tickets/sprints sur le transport web (web-server/lib.rs),
avec factorisation des DTO tickets partagés entre Tauri et web dans un
nouveau module backend/src/ticket_dto.rs (app-tauri/src/tickets.rs
consomme désormais ce module commun).

Lot 1 du ticket #86, backend/web-server. Le lot 2 (frontend) suit sur une
nouvelle branche depuis develop à jour.

QA vert.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-21 07:20:39 +02:00
5d262231e2 Merge feature/ticket83-quit-confirm-work-in-progress into develop
Ticket #83 : popup de confirmation à la fermeture d'IdeA si travail en
cours — guard backend (agents busy + tâches d'arrière-plan actives,
GetAppExitWorkGuardState) + popup frontend. QA vert.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-20 19:18:52 +02:00
60f4b33e53 feat(backend): guard de fermeture "travail en cours" (#83)
Expose l'état du guard de sortie applicative (GetAppExitWorkGuardState) :
agents busy + tâches d'arrière-plan actives à travers tous les projets
ouverts, avec détails compacts pour la popup de confirmation. Le handler
CloseRequested d'app-tauri interroge ce guard avant de laisser la fenêtre
se fermer, et respecte la confirmation explicite de l'utilisateur
(EXIT_GUARD_CONFIRMED) pour ne pas la redemander en boucle.

QA vert (backend + frontend).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-20 19:18:39 +02:00
8509653e3c feat(frontend): popup de confirmation à la fermeture avec travail en cours (#83)
Écoute l'event Tauri `app-exit-work-guard` (émis par le backend quand la
fermeture de la fenêtre main est interceptée) et affiche une popup modale
"Du travail est encore en cours" avec le résumé pluralisé exact du carnet
#83, le détail agents/tâches capé à 5 lignes, et les deux actions Annuler
(focus par défaut, no-op local) / Quitter quand même (danger, appelle
confirm_app_exit). Pas d'option "ne plus demander".

- domain/ports/adapters (Tauri listen+invoke, HTTP desktop-only stub, mock
  avec helpers de test) : onAppExitWorkGuard/confirmAppExit sur
  SystemGateway, suivant le patron déjà utilisé pour focused-project et les
  domain events.
- AppExitConfirmDialog : mounted une fois près de la racine (App.tsx), à
  côté d'AnnouncementsProvider — role="alertdialog", focus trap, Échap =
  Annuler, pas de fermeture au clic extérieur, ne se referme jamais
  automatiquement (un event pendant l'ouverture rafraîchit juste le résumé).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-20 19:16:29 +02:00
294865f805 Merge feature/ticket81-mcp-templates-editing into develop
Ticket #81 : MCP d'édition de templates — catalogue/classification (B1),
use cases/provider (B2), enforcement policy (B3). QA vert.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-20 18:45:07 +02:00
ef84d5cc49 feat(backend): MCP d'édition de templates (#81)
Ajoute le MCP dédié à l'édition de templates : catalogue et classification
des templates (mcp/templates.rs infrastructure + app-tauri), use cases et
provider (application/template), enforcement de la policy des tools (mod.rs,
server.rs, tools.rs), avec la parité côté chemin OpenAI-compatible
(openai_tools.rs x2).

Lots B1 (catalogue/classification), B2 (use cases/provider) et B3
(enforcement policy) livrés en un seul commit cohérent.

QA vert (seul l'échec de bind loopback #80, connu et non-régression, écarté).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-20 18:45:02 +02:00
448edfc364 Merge feature/ticket82-mcp-tools-permissions-ui into develop
Ticket #82, lot UX/Frontend : surface de gestion des permissions des tools
MCP par agent (Permissions panel), consommant l'API Tauri livrée en B4. QA
vert (858/858, tsc propre, stable sur shuffle hormis le flake #85, hors
périmètre).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-18 23:39:12 +02:00
c3078875f4 feat(frontend): surface MCP tool permissions per agent — Permissions panel (#82 lot UX/F)
Adds the "Tools MCP IdeA" tab to the project Permissions panel, alongside
the existing "Système" (file/command) tab. Lets the user grant/revoke MCP
tool capabilities per agent or project-wide default, grouped by domain
(Lecture projet, Lecture tickets, Délégation agents, Contexte et mémoire,
Tickets, Travail et exécution, Skills) instead of a flat 25-checkbox list,
per the UX conception in carnet #82.

- domain/ports/adapters (Tauri, HTTP, mock): wire get_mcp_tool_permissions,
  update_project_mcp_tool_permissions, update_agent_mcp_tool_permissions
  (already merged backend API, #82 lots B1-B4) onto PermissionGateway.
- useMcpToolPermissions: view-model owning the durable MCP tool policy
  document, distinct from the file/command permissions in usePermissions.
- McpToolPermissionsPanel: target selector (Défaut projet + agents with
  Hérité/Override badges) and grouped editor — inherited agents are
  read-only until "Créer un override" (prefilled with the effective
  allowlist), per-row Ajouté/Retiré diffing against the project default,
  inline confirmation before granting a write tool at project-default
  level, and unsaved-draft protection on target change.
- mcpToolGroups.ts: presentational-only domain grouping and short French
  labels — the read/write classification itself always comes from the
  backend-provided catalogue, never hardcoded here.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-18 23:36:02 +02:00
2db37a50fa chore(fmt): reformatage cargo fmt résiduel
Deux reformatages sans changement de comportement (device.rs, web-server/lib.rs),
laissés de côté hors périmètre au fil de plusieurs tickets précédents.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-18 23:15:39 +02:00
5f15cdbf28 Merge feature/ticket82-mcp-tools-catalog-permissions into develop
Ticket #82 : catalogue et permissions des tools MCP, backend complet en 4
lots — B1 domaine/store durable, B2 enforcement au serveur MCP stdio, B3
parité enforcement sur le chemin OpenAI-compatible, B4 API Tauri pour la
future UI de gestion. QA vert sur chaque lot.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-18 23:15:12 +02:00
c84a66f4e8 feat(backend): API Tauri pour la gestion des permissions tools MCP (#82 lot B4)
Expose au niveau application/DTO/commandes Tauri le catalogue et les
permissions des tools MCP (application/mcp_tool_permissions.rs, dto.rs,
commands.rs) pour une future UI de gestion.

Lot B4 du ticket #82, dernier lot backend : ferme la boucle sur B1
(domaine/store) + B2 (enforcement MCP stdio) + B3 (parité
OpenAI-compatible).

QA vert.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-18 23:15:05 +02:00
eeba0ddb46 feat(backend): parité enforcement des permissions tools sur le chemin OpenAI-compatible (#82 lot B3)
backend/src/openai_tools.rs et app-tauri/src/openai_tools.rs appliquent
désormais les mêmes règles de permission du domaine mcp_tool_permissions
(B1) et le même enforcement que le serveur MCP natif (B2), pour fermer
l'écart de parité sur le chemin OpenAI-compatible.

Lot B3 du ticket #82 : parité posée sur B1+B2, l'API backend pour la future
UI suit en B4 sur la même branche.

QA vert.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-18 23:03:33 +02:00
37ead61911 feat(backend): enforcement des permissions tools MCP au serveur (#82 lot B2)
orchestrator/mcp/server.rs applique désormais les règles de permission du
domaine mcp_tool_permissions (lot B1) à l'invocation d'un tool, y compris
le cas requester vide.

Lot B2 du ticket #82 : ferme la boucle enforcement sur le socle B1, la
parité OpenAI-compatible suit en B3 sur la même branche.

QA vert (32 tests dont le nouveau cas requester vide).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-18 22:54:42 +02:00
5175589aa5 feat(backend): domaine + catalogue et store durable des permissions tools MCP (#82 lot B1)
Introduit le domaine mcp_tool_permissions (règles de permission par tool
MCP) et étend le port de store correspondant. Le catalogue read/write des
tools MCP (orchestrator/mcp/tools.rs) s'appuie désormais sur ces règles, et
un store durable (mcp_tool_permission.rs) persiste les permissions au-delà
d'une session.

Lot B1 du ticket #82 : pose le socle domaine/store, l'enforcement suit en
B2 sur la même branche.

QA vert.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-18 22:45:32 +02:00
32408b5232 Merge feature/ticket62-requester-identity-tool-policy into develop
Ticket #62 : identité requester explicite pour les sessions structurées et
policy des tools OpenAI-compatible (ToolPolicyRegistry branché sur
AppOpenAiToolInvoker). QA vert.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-18 22:35:23 +02:00
b4a34b40e5 fix(backend): identité requester explicite + policy des tools OpenAI-compatible (#62)
AgentSessionFactory::start propage désormais l'identité du requester aux
sessions structurées ; OpenTicketAssistant et LaunchAgent la portent
correctement de bout en bout. ToolPolicyRegistry est branché sur
AppOpenAiToolInvoker pour combler le trou de parité : TicketToolProvider
n'appliquait pas la policy des tools sur le chemin OpenAI-compatible,
contrairement au chemin structuré natif.

QA vert (échecs de bind loopback écartés comme non-régression préexistante,
tracés en #80).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-18 22:35:17 +02:00
a7abd331b8 Merge feature/ticket79-flaky-permissions-test into develop
Ticket #79 : fix du flake PermissionsPanel > saves project defaults
(PermissionEditor draft resync clobbering in-flight edits). QA vert sur le
périmètre du ticket (2/2 stable + suite complète non-shuffled) ; le rouge
observé en shuffle vient d'un autre test préexistant sans rapport
(setCellAgent.test.tsx, tracé séparément en #85).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-18 14:57:44 +02:00
8387c1bbdf Merge feature/ticket78-settings-french-labels into develop
Ticket #78 : alignement des libellés Settings desktop sur le français, QA
vert (850/850 tests, tsc propre).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-18 14:57:37 +02:00
6e92536d84 fix(frontend): align Settings desktop labels on French (#78)
UX decision (carnet #78): the human UI of IdeA is French by default,
uniform per surface — proper nouns and technical acronyms (URL, LAN,
IP/CIDR, HTTPS, API, CLI…) stay as-is. Settings mixed English (AI
Profiles, Deployment) with French (Appareils, frozen by UX for #77).

Renames the Settings menu/nav, the Profils IA and Déploiement panels
(titles, actions, states, help text) to French, per the carnet's
exhaustive list. Updates the affected tests accordingly.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-18 14:53:32 +02:00
348bccae34 fix(frontend): stop PermissionEditor draft resync from clobbering in-flight edits (#79)
The draft-resync useEffect fired on every new `draft` object (initial load,
refresh, another save), even when its content matched `local`. If it flushed
after the user started editing, it silently discarded the edit — flaky in
tests where a passive effect can settle after a synchronous fireEvent
sequence, and a real risk in production if a fetch lands mid-edit. Now it
only resyncs when `local` still matches the last-adopted draft.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-18 14:49:22 +02:00
a69c5db093 Merge feature/ticket61-cells-refit into develop
Ticket #61 : refit différé des cellules terminal après split/merge, QA vert
(850/850 tests, tsc propre, test refitSignal dédié).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-18 09:41:44 +02:00
445ecaf82e fix(frontend): refit différé des cellules terminal après mutation de layout (#61)
Le ResizeObserver de TerminalView ne déclenche pas toujours un événement
utile quand une cellule voisine apparaît/disparaît (split/merge), forçant
l'utilisateur à redimensionner la fenêtre pour rafraîchir le scaling xterm.
useLayout expose un layoutVersion bumpé à chaque commit d'arbre (chargement
initial inclus), relayé par LayoutGrid comme refitSignal à chaque
TerminalView survivant pour déclencher fit.fit() sans rouvrir le PTY.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-18 09:41:39 +02:00
17d6baf15a Merge feature/ticket77-paired-devices into develop
Intègre le ticket #77 : l'appairage repose désormais sur des appareils
persistants, nommés et révocables, derrière un code éphémère à usage
unique (TTL 10 min) au lieu d'un code permanent imprimé sur stdout.

Ferme aussi la dette #76 : la normalisation du code passe côté serveur,
là où #75 ne pouvait que la masquer depuis le frontend.

Suites rejouées avant merge, toutes vertes :
- cargo test -p domain -p application -p infrastructure -p web-server :
  exit 0, 89 suites, 1686 tests.
- frontend : 91 fichiers, 848 tests, tsc exit 0.
- garde-fou de bundle : dist = tauri, dist-web = http.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 13:27:17 +02:00
1be5f8cd18 chore(ideai): #77 en QA, ouverture de #78 et #79
Enregistre l'état du registre de tickets : #77 entre en QA, #78 ouvre la
dette UX de langue de l'écran Settings et #79 le test flaky relevé en
cours de route.

État runtime uniquement : aucun code de feature n'est touché.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 13:27:06 +02:00
3f1e132e88 feat(frontend): écran Appareils et parcours d'appairage nommé (#77 F1/F2)
Expose la gestion des appareils appairés introduite en B1-B4, sur une
surface unique partagée par le web et le desktop.

- Écran Appareils : liste, renommage, révocation unitaire ou globale,
  activité formatée, panneau de code éphémère.
- Le parcours d'appairage demande un nom d'appareil, pour qu'une
  révocation porte sur quelque chose d'identifiable par l'utilisateur.
- Gateways DeviceGateway en trois adapters (Tauri, HTTP, Mock), le port
  restant le seul contrat connu de la feature.

Les erreurs sont mappées localement et le message du serveur n'est jamais
affiché tel quel : un échec d'appairage ne doit pas devenir un oracle pour
qui teste des codes.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 13:27:06 +02:00
8fe93d1652 feat(backend): appareils appairés persistants, révocables et code éphémère (#77 B1-B4)
L'appairage ne survivait pas au redémarrage et son code, permanent, était
imprimé sur la sortie standard. Un appareil appairé devient une entité
persistante, nommée et révocable, derrière un code désormais éphémère.

- B1 : port DeviceSessionStore et adapter FsDeviceSessionStore, entités de
  domaine (PairedDevice, DeviceId, SessionTokenHash, DeviceName). Les tokens
  sont hachés en SHA-256 et comparés en temps constant (subtle) : le store
  ne peut pas rejouer une session qu'il a servie. Cookie Max-Age 400 j à
  renouvellement glissant, lastSeenAtMs throttlé.
- B2 : code éphémère en mémoire, TTL 10 min et usage unique, toute
  génération invalidant la précédente. POST /api/pairing-code authentifiée,
  flag --new-code. Le code est retiré du boot et l'eprintln! qui l'imprimait
  est supprimé.
- B3 : endpoints devices (list/rename/revoke/revoke-all/logout), event
  DeviceRevoked et ActiveConnectionRegistry par device_id, fermant sans
  délai les WebSockets d'un appareil révoqué.
- B4 : port PairAttemptLimiter et adapter mémoire, rate-limit par origine et
  global sur horloge injectée, donc testable sans attente réelle.

La normalisation du code passe côté serveur : elle absorbe la dette #76, que
la seule normalisation frontend de #75 ne faisait que masquer.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 13:26:56 +02:00
9463b7e6bf Merge feature/ticket75-pairing-code-keyboard into develop
Intègre le ticket #75 : l'écran d'appairage web appelait le pavé
numérique des mobiles alors que le code d'appairage est de
l'hexadécimal majuscule, rendant les lettres A-F non saisissables.

Le champ passe en clavier texte, annonce le format réel et normalise
la saisie avant envoi. Le correctif revient sur le choix de #69, qui
avait supposé un code purement numérique.

Suite verte rejouée avant merge : 88 fichiers, 801 tests, tsc exit 0.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 10:41:01 +02:00
481a7e2498 chore(ideai): clôture de #74 et #68, ouverture de #75 et #76
Enregistre l'état du registre de tickets : #74 et #68 passent en closed
après la validation live de l'intégration web, #75 (ce fix) entre en QA
et #76 ouvre la dette de casse du code d'appairage côté serveur.

État runtime uniquement : aucun code de feature n'est touché.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 10:40:26 +02:00
120d0d1ac2 fix(frontend): clavier texte et normalisation du code d'appairage (#75)
Le code d'appairage est de l'hexadécimal majuscule (p. ex. 3F7A9C21),
pas une suite de chiffres. Le champ appelait pourtant le pavé numérique
des mobiles, rendant les lettres A-F non saisissables.

Le champ passe donc en inputMode="text" avec autoCapitalize="characters",
ce qui revient sur le choix inverse fait en #69 : ce ticket avait supposé
un code purement numérique. Le placeholder et l'aide du champ décrivent
désormais le format réel.

La saisie est normalisée (majuscules, espaces retirés) avant pair() car
le serveur compare le code strictement ; la dette correspondante côté
backend est suivie en #76.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 10:40:26 +02:00
aec4293750 Merge feature/ticket74-web-transport-bundle into develop
Intègre les tickets #68 (packaging des assets web en ressource Tauri) et
#74 (le serveur embarqué servait le bundle desktop au navigateur).

Le frontend produit désormais deux artefacts Vite distincts : dist
(transport tauri, build.frontendDist) et dist-web (transport http,
packagé en ressource « web/ »). Le garde-fou de build échoue si un
bundle résout le mauvais transport.

Les deux tickets ferment ensemble : le packaging #68 servait le bundle
cassé, il ne pouvait pas être déclaré vert sans le fix #74. Validation
live utilisateur verte derrière reverse proxy.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 10:34:32 +02:00
4de25d2bce chore(ideai): état runtime du ticket #74 (passage en QA)
Enregistre le passage de #74 en statut QA (issue, carnet, index) et
l'accusé de complétion des rendez-vous headless du lot.

État runtime uniquement : aucun code de feature n'est touché.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 10:34:24 +02:00
f605989fa5 chore(ideai): note mémoire du seam de transport des bundles (#74)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 09:09:46 +02:00
25728dee74 test(frontend): garde-fou sur le transport des bundles construits (#74 Q1)
Vérifie sur les artefacts réels que `dist` résout `tauri` et `dist-web`
`http`, en lisant le marqueur `__IDEA_TRANSPORT__` des assets JS émis. La
régression de #74 était invisible aux tests unitaires : elle vivait dans la
conf de build et de packaging, pas dans le code testé.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 09:09:42 +02:00
5ca2ab77f3 fix(app-tauri): packager le bundle web, pas le bundle desktop (#74 B1)
`bundle.resources` packageait `frontend/dist` — le bundle desktop — sous
`web/`, que `resolve_web_root()` sert au navigateur. La ressource pointe
désormais sur `frontend/dist-web` (transport http), et `beforeBuildCommand`
appelle `build:bundle` pour que les deux bundles existent au packaging.

`frontendDist` reste sur `dist` : le desktop est inchangé.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 09:09:42 +02:00
a7197fc53b feat(frontend): produire un bundle web distinct en transport http (#74 F1)
Le transport est figé au build par Vite : un seul `dist` ne peut pas servir
à la fois le desktop (IPC Tauri) et le navigateur (HTTP+WS). Le serveur
embarqué servait donc un bundle desktop, d'où `__TAURI_INTERNALS__ is
undefined` côté navigateur.

- `vite.config.ts` devient une factory `({ mode })` : le mode par défaut émet
  le bundle desktop (`dist`), `--mode web` lit `.env.web` et émet le bundle
  navigateur (`dist-web`).
- `.env.web` porte `VITE_TRANSPORT=http` dans un fichier de mode plutôt qu'en
  préfixe de commande, syntaxe qui n'existe pas sous Windows (bundle NSIS).
- `transport.ts` extrait le prédicat `transportFromEnv()`, partagé par l'app et
  la config de build : le constant `__IDEA_TRANSPORT__` et le transport résolu
  dérivent de la même variable via le même prédicat, ils ne peuvent pas diverger.
- `main.tsx` publie `__IDEA_TRANSPORT__` sur `window` : l'affectation est un
  effet de bord, elle survit à la minification et rend un bundle identifiable
  sans grep d'un symbole minifié. Les deux jeux d'adapters étant présents dans
  les deux bundles, leur présence ne prouve rien.

Le chemin desktop est inchangé : le web reste opt-in.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 09:09:33 +02:00
50d237e836 chore(ideai): ouverture du ticket #74 (bundle desktop servi au navigateur)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 08:54:19 +02:00
166adc3c4b feat(app-tauri): packager les assets web en ressource et les résoudre depuis le resource dir (#68)
L'AppImage ne pouvait pas servir d'assets web : `resolve_web_root` ne
connaissait que `IDEA_WEB_ROOT`, le dossier de l'exécutable et le cwd —
aucun ne pointe vers un bundle packagé.

- `bundle.resources` embarque les assets sous `web/`, `beforeBuildCommand`
  déclenche le build du frontend.
- Le resource dir Tauri descend de `lib.rs` jusqu'à `EmbeddedServerController`
  via `AppState::build_with_resource_dir`, en gardant les constructeurs
  historiques comme façade.
- `resolve_web_root` insère le candidat packagé juste après `IDEA_WEB_ROOT`,
  qui garde donc la priorité pour le développement.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 08:54:15 +02:00
a13a6c1801 chore(ideai): carnet de #68, passage en QA et note du faux vert sandbox
Dernier état `.ideai/` du sprint serveur embarqué, séparé du code applicatif
conformément aux précédents `f965f64` / `7fbaa8e` / `5ee25d1`.

- #68 passé en `qa`, pas en `closed` : mergé dans `develop` (`b30c9c7`) et vert,
  mais RIEN n'a été cliqué dans l'app réelle. « Mergé » ne veut pas dire
  « validé » — même distinction que pour #69 et son lot 3.
- Carnet de #68 : périmètre livré, réserve « aucune validation live », et la
  dette identifiée (ordre de `preview_settings` qui verrouille la liste des
  candidats LAN, warning `missingTrustedProxy` inatteignable).
- Mémoire projet : note `sandbox-eperm-bind-false-green-web-server`. Elle
  capitalise le piège qui s'est refermé DEUX FOIS le 2026-07-16 : les sandboxes
  de DevBackend et QA refusent `TcpListener::bind`, donc tout `cargo test` sur
  `web-server`/`app-tauri` y rend un vert qui ne prouve rien. La première fois,
  ce faux vert masquait un vrai bug produit — un serveur embarqué sur port
  éphémère rejetait toutes les requêtes API en 403. La règle qui en sort : aucun
  repli EPERM silencieux, et tout vert sur ces crates doit être produit hors
  sandbox.
- Journal des tâches de fond : complétions enregistrées.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 06:03:11 +02:00
f965f64b07 chore(ideai): clôture de #72 (confiance reverse proxy)
#72 passé en `closed` : mergé dans `develop` via `ae01297`, vert hors sandbox,
branche supprimée. Carnet complété avec le périmètre livré et les arbitrages.

État `.ideai/` indépendant du code de #68, committé directement sur `develop`.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 23:44:12 +02:00
b30c9c7590 Merge feature/ticket68-embedded-server-desktop into develop (#68)
Ferme #68 : le serveur web s'active désormais depuis l'app desktop, via un
panneau Settings > Deployment. C'est la fonctionnalité demandée à l'origine du
ticket, et l'aboutissement de la chaîne #65 (extraction d'idea-serve) → #68 B1
(seam shared-core) → #72 (durcissement proxy) → ce lot.

Backend : `EmbeddedServerController` sur `AppState`, commandes start/stop/status,
store `<app-data-dir>/deployment/server-exposure.json` (config de sécurité, pas
préférence d'UI), arrêt câblé sur la sortie d'app. Le serveur embarqué consomme
`run_embedded_with_core` avec le `BackendCore` du desktop — une seule
composition root, ce pour quoi le seam de B1 existait.

Frontend : `features/settings/` avec `SettingsView`/`DeploymentSettings`,
gateway `DesktopServerGateway`, et `ProjectsView` dont le booléen `showSettings`
devient une vraie navigation `AI Profiles` / `Deployment`.

Vert avant merge, ré-exécuté par Git HORS SANDBOX — impératif sur ces crates,
le sandbox bloque `bind` et a déjà produit un faux vert sur #68 B1 :
`cargo test -p app-tauri` 43 passed / 1 ignored · `-p web-server` 66 passed ·
`npm run typecheck` exit 0 · `npx vitest run` 87 files / 789 passed. Le test
ignoré est une garde d'environnement préexistante, vérifiée passante hors
sandbox avec `--ignored`.

Invariants vérifiés par Git avant merge : `run_embedded_with_core` bien
l'appelant, aucune fuite des types d'exposition dans `domain`/`application`,
`0600` posé avant le `rename`, `stop()` appelé à la fermeture.

Dette consignée, non bloquante : `preview_settings` valide avant de
prévisualiser (verrouille la liste des candidats LAN, contourné côté frontend),
et le warning `missingTrustedProxy` est inatteignable.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 23:43:56 +02:00
7efa634f23 feat(frontend): panneau Settings Deployment et gateway serveur desktop (#68 F1+F2)
Donne à l'utilisateur la surface pour activer le serveur depuis l'app.

- `features/settings/` : `SettingsView`, `DeploymentSettings`, `useDeployment`.
- `adapters/desktopServer.ts` + port `DesktopServerGateway` et DTO associés ;
  adapters mock et http/unsupported alignés (le mode web n'expose pas le
  contrôle du serveur qui l'héberge).
- `ProjectsView` : le `showSettings: boolean` devient une navigation interne
  `AI Profiles` / `Deployment`. Le libellé alternant « Close AI Profiles »
  disparaît — Settings existait déjà dans cette vue, la surface évolue au lieu
  d'ajouter un `PanelId`.

CORRECTION D'UN BRIEF FAUX, remontée spontanément par DevFrontend et qui mérite
de survivre : le cadrage décrivait le mode `remoteProxyOtherMachine` avec deux
champs. `validate_settings` en exige un troisième, `lanBindAddress`, et rejette
loopback comme unspecified. Construit selon la spec, chaque save et chaque start
en mode 3 aurait échoué — le lot serait parti vert et cassé. Le panneau expose
donc un select alimenté par `candidateLanAddresses` fourni par le backend :
la règle « le frontend n'invente jamais une IP » tient.

QA ré-exécutée par Git avant merge : `npm run typecheck` exit 0 ·
`npx vitest run` 87 files / 789 passed, 0 échec.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 23:43:37 +02:00
49e1d5a157 feat(app-tauri): cycle de vie du serveur embarqué et persistance de l'exposition (#68 B2)
Permet d'activer le serveur web depuis l'app desktop — la fonctionnalité
demandée à l'origine du ticket.

- `embedded_server.rs` : `EmbeddedServerController` porté par `AppState`, avec
  les commandes `embedded_server_start` / `stop` / `status` et
  `get` / `save` / `preview_server_exposure_settings`.
- `FsServerExposureSettingsStore` : écrit `<app-data-dir>/deployment/server-exposure.json`.
  C'est de la config de sécurité, pas une préférence d'UI — d'où l'app-data-dir
  global plutôt que `localStorage`. Écriture atomique : temporaire, `0600` posé
  AVANT le `rename`, donc le fichier final n'est jamais brièvement lisible par
  tous.
- Arrêt du serveur câblé sur la sortie de l'app (`lib.rs`), aux côtés des autres
  nettoyages.

Le serveur embarqué appelle `run_embedded_with_core` avec le `BackendCore`
partagé du desktop, jamais `run_embedded` — c'est tout l'intérêt du seam ouvert
par B1 : une seule composition root dans le processus, pas deux.

DETTE CONNUE, consignée au carnet, non bloquante :
- `preview_settings` valide avant de prévisualiser (`embedded_server.rs:211`),
  ce qui verrouille la liste des candidats : un brouillon en mode
  `remoteProxyOtherMachine` ne peut pas être prévisualisé tant qu'il n'a pas le
  `lanBindAddress` que cette liste doit justement fournir. Contourné côté
  frontend par une sonde `localOnly` toujours valide. Défaut d'ordonnancement,
  pas une fatalité.
- Le warning `missingTrustedProxy` (`embedded_server.rs:452`) est du code mort :
  `validate_settings` rejette les `trustedProxies` vides en mode 3 avant que
  `preview_settings` ne puisse le produire.

QA ré-exécutée par Git HORS SANDBOX (DevBackend et QA sont bloqués par EPERM sur
`bind` ; un vert sandboxé ne prouve rien sur ces crates) : `cargo test -p
app-tauri` 43 passed, 1 ignored · `-p web-server` 66 passed, 0 échec.
Le test ignoré `mcp_bridge::tests::end_to_end_over_real_loopback` est
PRÉEXISTANT sur `develop` et non touché par ce lot ; lancé explicitement hors
sandbox avec `--ignored`, il passe. C'est une garde d'environnement, pas un faux
vert — distinction qui nous a déjà coûté deux fois aujourd'hui.

Invariants vérifiés par Git : appelant `run_embedded_with_core` confirmé, aucune
fuite d'`EmbeddedServer*`/`ServerExposure*` dans `domain` ni `application`,
ordre chmod/rename correct, `stop()` bien appelé à la fermeture.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 23:43:24 +02:00
7fbaa8eba6 chore(ideai): ouverture de #73 (TLS intégré à idea-serve)
#73 ouvert en priorité haute : intégrer TLS à `idea-serve` pour supprimer la
cause racine de la cérémonie reverse proxy, dont #72 vient de durcir les
garde-fous. Lié à #72, #66, #68 et #71.

État `.ideai/` indépendant du code de #72, committé directement sur `develop`.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 23:11:15 +02:00
ae01297b6b Merge feature/ticket72-proxy-trust-hardening into develop (#72)
Rend réelle la confiance accordée au reverse proxy. Jusqu'ici
`--trust-reverse-proxy` n'était lu que pour exiger sa propre présence : le
serveur ne vérifiait ni qui se connectait, ni ce que le proxy annonçait. Le pair
TCP est désormais vérifié avant toute confiance aux headers, `X-Forwarded-Proto:
https` est exigé en mode proxy, et `X-Forwarded-For` n'autorise jamais rien.

Corrige aussi B0, le pendant CLI du bug de port de #68 B1 : `idea-serve --listen
127.0.0.1:0` ne compare plus l'origine à `http://127.0.0.1:0`.

CHANGEMENT DE COMPORTEMENT ASSUMÉ : un bind non-loopback distant sans
`--trusted-proxy` est refusé au démarrage. Les configurations existantes de cette
forme cassent volontairement, avec un message qui dit quoi ajouter.

Vert avant merge, ré-exécuté par Git HORS SANDBOX — impératif sur ce crate, le
sandbox interdit `TcpListener::bind` et a déjà produit un faux vert sur #68 B1 :
`cargo test -p web-server` 66 passed · `-p backend` · `-p app-tauri` verts.
Revue de sécurité : guard câblé sur les 3 surfaces (statique, /api/*, /api/ws),
vrai `peer_addr` propagé sur tout le chemin de production.

Étape 2 du plan d'intégration séquentiel. Suit : #68 (panneau Settings
Deployment), sur arbitrage utilisateur qui a refusé de le reléguer derrière #71
et #73.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 23:11:04 +02:00
42804fc55d docs(server): documenter --trusted-proxy et l'exigence X-Forwarded-Proto (#72)
Aligne la doc du mode distant sur le durcissement de #72 : exemple complet du
cas proxy sur une autre machine avec `--trusted-proxy`, mention que tout bind
non-loopback exige au moins un proxy autorisé, et obligation faite au proxy
d'envoyer `X-Forwarded-Proto: https`.

Précise que transmettre le host public est recommandé pour le diagnostic mais
n'est pas la vérification d'accès : celle-ci reste l'égalité stricte d'`Origin`
contre `--public-origin`.

Bascule les IP d'exemple vers la plage de documentation RFC 5737 (`192.0.2.0/24`)
au lieu d'un réseau privé plausible.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 23:10:47 +02:00
75d1ce87fc feat(web-server): donner un effet réel à la confiance reverse proxy + fix port CLI (#72)
`--trust-reverse-proxy` était un drapeau creux : il n'était lu que dans
`ServerConfig::validate()` pour exiger sa propre présence. Le serveur n'a jamais
vérifié qui se connectait ni ce que le proxy annonçait. Ce lot lui donne un
effet.

- `trusted_proxies: Vec<TrustedProxy>` dans `ServerConfig` + `--trusted-proxy`
  (répétable, IP ou CIDR v4/v6). `validate()` refuse désormais au démarrage un
  bind non-loopback en mode remote sans au moins un proxy autorisé.
- Guard runtime sur les trois surfaces (statique, `/api/*`, `/api/ws`) : le
  `peer_addr` réel est vérifié AVANT toute confiance accordée aux headers. Sur
  bind loopback, seul un pair loopback est accepté ; sinon le pair doit tomber
  dans un `--trusted-proxy`.
- `X-Forwarded-Proto: https` obligatoire en mode proxy, avec un message de refus
  actionnable (la commande nginx exacte à ajouter).
- `X-Forwarded-For` n'autorise jamais rien : il n'est que journalisé. Un header
  ne donne aucun droit, seul le pair TCP en donne.
- Diagnostics : `UntrustedProxyPeer`, `ForwardedProtoRejected`,
  `ForwardedHostMismatch`.

B0 — même bug de port que celui corrigé dans #68 B1, sur le chemin CLI cette
fois : `run_server` construisait son `ServerState` AVANT le bind, donc
`idea-serve --listen 127.0.0.1:0` comparait l'origine à `http://127.0.0.1:0` et
rejetait tout en 403. La réconciliation du port effectif est factorisée dans
`config_with_effective_listen`, partagée avec le chemin embarqué.

`X-Forwarded-Host` ne provoque PAS de rejet : Architect l'a jugé redondant avec
la vérification stricte d'`Origin`, et il cassait nginx en configuration par
défaut. Il reste un warning de diagnostic. La vérification d'accès stricte
demeure l'égalité d'`Origin` contre `--public-origin`.

CHANGEMENT DE COMPORTEMENT ASSUMÉ — ce lot casse volontairement les
configurations existantes : un bind non-loopback distant sans `--trusted-proxy`
est désormais refusé au démarrage. C'est le prix d'un drapeau qui ne mentait
plus. Le message d'erreur dit quoi ajouter.

Origine du ticket : #72 est né d'une trouvaille de l'agent Git à la revue de la
doc de #65 — c'est en vérifiant une phrase de sécurité qu'il a établi que
`--trust-reverse-proxy` n'avait aucun effet runtime.

QA ré-exécutée par Git HORS SANDBOX avant merge (DevBackend et QA sont tous deux
bloqués par EPERM sur `TcpListener::bind` ; un vert sandboxé ne vaut rien ici, on
s'est déjà fait avoir sur #68 B1) : `cargo test -p web-server` 66 passed, 0
échec · `-p backend` · `-p app-tauri` verts.

Revue de sécurité par Git : guard câblé sur les 3 routes, chemin de production
propageant toujours le vrai `peer_addr` (le repli `listen.ip()` est
`#[cfg(test)]`, inatteignable en production), CIDR correct y compris `prefix 0`.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 23:10:40 +02:00
e8a72f5173 Merge docs/remote-mode-proxy-clarification into develop (#65)
Corrige une documentation qui a réellement induit l'utilisateur en erreur :
l'exemple du cas « Remote HTTPS » bindait `127.0.0.1` en supposant sans le dire
que le reverse proxy est co-localisé. Suivi tel quel avec un proxy sur une autre
machine, il produit un serveur injoignable.

Précise le cas co-localisé vs le cas distant, la configuration exigée pour tout
bind non-loopback, l'égalité stricte de `--public-origin` contre l'`Origin`
(ouvrir l'UI par le domaine, pas par l'IP, sinon 403), et le pare-feu hôte comme
cause de timeout depuis les autres machines.

Conserve l'obligation normative « ne pas exposer sans proxy TLS » que la
première rédaction avait perdue au profit d'une garantie que le code n'offre
pas : `ServerConfig::validate()` valide la configuration, pas la présence réelle
d'un proxy.

Indépendant de #68 et #71 : n'a attendu aucun de leurs lots.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 18:51:23 +02:00
677f64d18e docs(server): restaurer l'obligation de proxy TLS, que validate() n'assure pas (#65)
La réécriture précédente avait remplacé « Do not expose the backend on a public
non-loopback address without TLS proxying » par une formulation adossée à
`ServerConfig::validate()`. Littéralement vraie, mais pas équivalente : elle
troque une OBLIGATION faite à l'opérateur contre une garantie automatique qui
n'existe pas.

`validate()` valide une configuration, pas la réalité. Rien ne vérifie qu'un
proxy est réellement devant le serveur : passer les trois drapeaux en bindant
`0.0.0.0` sans aucun proxy satisfait `validate()` et sert du HTTP en clair.
La phrase normative est donc rétablie, avec cette limite dite explicitement.

Voir #72 : `--trust-reverse-proxy` n'a par ailleurs aucun effet à l'exécution.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 18:51:11 +02:00
f915635e07 chore(ideai): ouverture de #72 (confiance reverse proxy sans effet réel)
- #72 ouvert en priorité haute, bloquant #68 : `--trust-reverse-proxy` n'est lu
  que dans `ServerConfig::validate()` pour exiger sa propre présence — le serveur
  ne parse jamais `X-Forwarded-*`. C'est un drapeau d'intention pur, qui donne un
  faux sentiment de protection. Le ticket porte aussi B0 (le bug de port effectif
  sur le chemin CLI `run_server`), `trusted_proxies` + `--trusted-proxy`, le
  guard runtime et les événements de diagnostic.
- Journal des tâches de fond : complétions enregistrées.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 18:50:57 +02:00
7c677c4fb4 docs(contexte): ajouter le rôle UX au contexte projet et au cycle obligatoire
Déclare UX comme propriétaire de la conception des surfaces (navigation,
libellés, hiérarchie de l'information, formulation des erreurs, parcours) et
l'insère dans le cycle : avant Architect quand la forme conditionne les contrats,
avec lui quand une contrainte technique borne la conception. UX ne bloque pas les
lots sans surface utilisateur.

Ajoute aussi l'avertissement que la liste des rôles de ce document n'est pas la
source de vérité des agents déclarés : `idea_list_agents` fait autorité.

Contexte projet, indépendant des chantiers en cours — committé directement sur
`develop`.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 18:50:50 +02:00
328c941f22 Merge feature/ticket68-embedded-server-core into develop (#68 B1)
Livre la fondation backend du serveur embarqué desktop : le seam
`run_embedded_with_core(config, Arc<BackendCore>)`, qui permet à l'app Tauri de
faire tourner le serveur web en partageant son composition root plutôt qu'en
dupliquant un backend dans le même processus.

Apporte aussi le fix du port effectif : un serveur embarqué sur port éphémère
rejetait toutes les requêtes API en 403 (origine comparée à un `listen` resté à
port 0). Et comble le trou de couverture sur `run_embedded().stop()` signalé au
merge de #65.

Vert avant merge, ré-exécuté par Git HORS SANDBOX — impératif ici : le sandbox
interdit `TcpListener::bind` et avait produit un faux vert sur ce lot précis.
`cargo test -p web-server` 57 passed (les 2 tests embedded réellement exécutés) ·
`-p backend` 41 · `-p app-tauri` 35, 0 échec.

Étape 1 du plan d'intégration séquentiel. Suit : #72 (durcissement bind/origine/
proxy, dont B0 = le même bug de port sur le chemin CLI `run_server`), puis #71
lot 1 (diagnostics), puis le Settings Deployment de #68.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 18:50:37 +02:00
b7d38f1d30 feat(web-server): seam shared-core run_embedded_with_core + fix du port effectif (#68 B1)
Ouvre le point d'intégration du serveur embarqué desktop : `run_embedded_with_core`
reçoit un `Arc<BackendCore>` déjà construit, pour que l'adapter HTTP partage le
composition root de l'adapter Tauri au lieu d'en bâtir un second dans le même
processus. `ServerState` porte désormais `Arc<BackendCore>` ; `run_embedded` est
conservé en compat et délègue en construisant son propre core.

Corrige au passage un vrai bug produit, découvert en rejouant les tests hors
sandbox : `run_embedded` ne réconciliait pas le port effectif avec la config. Sur
un bind éphémère (`127.0.0.1:0`), l'état du serveur gardait `listen` à port 0,
donc `origin_allowed` comparait l'Origin entrante à `http://127.0.0.1:0` et le
serveur embarqué rejetait **toutes** les requêtes API en 403. La config reçoit
maintenant `local_addr` lu sur le listener **avant** la construction du state.

Comble le trou signalé au merge de #65 : `run_embedded().stop()` est enfin
couvert.

ATTENTION — le premier « 57 passed » de ce lot était un FAUX VERT. Le sandbox
d'exécution interdit `TcpListener::bind` ; les tests sortaient en silence sur
EPERM, dont précisément le test `stop()`. Les replis EPERM sont supprimés : un
bind refusé fait désormais échouer le test au lieu de le peindre en vert.

QA ré-exécutée par Git HORS SANDBOX avant merge (sinon on reproduit le faux
vert) : `cargo test -p web-server` 57 passed, 0 échec, avec
`run_embedded_stop_shuts_down_accept_loop` et
`run_embedded_with_core_uses_injected_core_for_http_invokes` réellement exécutés
sur le vrai chemin réseau. `-p backend` 41 · `-p app-tauri` 35, 0 échec.

DETTE CONNUE, tracée en #72 B0 : le chemin CLI standalone `run_server` garde la
même hypothèse fausse — il reçoit un `ServerState` construit AVANT le bind, donc
`idea-serve --listen 127.0.0.1:0` reste cassé à l'identique.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 18:50:18 +02:00
77684ea183 docs(server): clarifier le bind du cas proxy distant et l'origine stricte (#65)
L'exemple du cas « Remote HTTPS » bindait `127.0.0.1` en supposant sans le dire
que le reverse proxy tourne sur la même machine que le serveur. Suivi tel quel
avec un proxy sur une autre machine, il produit un serveur injoignable — ce qui
a réellement induit l'utilisateur en erreur aujourd'hui.

Précise donc : le cas co-localisé vs le cas proxy distant (binder une adresse
joignable par le proxy, lien proxy→serveur en HTTP clair sur le LAN), la
configuration exigée pour tout bind non-loopback, l'égalité stricte de
`--public-origin` contre l'`Origin` de la requête (ouvrir l'UI par le domaine et
non par l'IP, sinon 403), et le pare-feu hôte comme cause de timeout depuis les
autres machines.

Indépendant de #68 et #71 : valeur immédiate, n'attend aucun de leurs lots.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 18:11:56 +02:00
56b9f5f619 chore(ideai): clôture de #65 et ouverture de #71 (diagnostic d'accessibilité)
État `.ideai/` indépendant des branches de feature, committé directement sur
`develop` (précédents `2fa226e`, `56757c7`).

- #65 « serveur headless idea-serve » passé en `closed` par Main : mergé dans
  `develop` via `fe0e53e`, vert, branche supprimée.
- #71 « diagnostic d'accessibilité du serveur » ouvert, lié à #68 et #65.
- Journal des tâches de fond : complétions enregistrées.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 18:11:38 +02:00
32c670a2b3 Merge feature/ticket69-mobile-responsive-client into develop (#69)
Rend le client web utilisable sur téléphone : `100dvh` + `viewport-fit=cover` et
safe-area insets (la barre d'URL rétractable masquait le bas), rangées qui
s'empilent sous 360px, et surtout une `TerminalKeyBar` (Esc/Tab/Ctrl-C/Ctrl-D/
flèches) qui rend le terminal pilotable au doigt — le clavier virtuel n'offre
aucune de ces touches, on pouvait donc parler à un agent CLI mais pas
l'interrompre.

Surface frontend-pure : aucun DTO, use case ni `LayoutTree` touché. Le chemin
desktop est inchangé (`LayoutGrid` ne passe pas `onReady`, `onReady` est
optionnel).

Vert avant merge, ré-exécuté par Git sur la base rebasée (les chiffres du carnet
ne valaient que sur `506d589`) : `npm run typecheck` exit 0 · `npx vitest run`
85 files / 774 passed, 0 échec · `VITE_TRANSPORT=http npx vite build` exit 0.

RÉSERVE — le lot 3 est livré mais NON PROUVÉ en conditions réelles.
La validation live utilisateur du 2026-07-16 (téléphone réel, via le reverse
proxy) est PARTIELLE. Couvert : le terminal s'ouvre, ce qui implique appairage +
workspace traversés, donc les lots 1 et 2 (`100dvh`, `60dvh`) validés en réel.
NON couvert : la `TerminalKeyBar` n'a pas été utilisée, et l'invariant de focus
au tap (« chaque tap annule le déplacement de focus puis refocalise xterm », sans
lequel le clavier virtuel se referme à chaque touche) n'a pas été observé sur
navigateur mobile réel. C'est le cœur du ticket. Le test manquant tient en 30 s :
lancer une commande longue, taper Ctrl-C dans la barre, vérifier que la commande
s'interrompt ET que le clavier reste ouvert.
Merge autorisé par Main sur ce constat : risque résiduel borné (frontend-pur,
desktop non atteint, non-régression prouvée). Si le test Ctrl-C échoue, il ouvre
un bug, il ne réverte pas ce merge. Jusque-là, « mergé » ne veut pas dire
« validé ».

Trou de couverture connu et assumé : jsdom n'évalue pas les media queries, les
tests sont structurels et ne prouvent ni les breakpoints, ni `dvh`, ni les safe
areas, ni le clavier virtuel. La décision d'ajouter un vrai navigateur
(Playwright) appartient à #63 « Système de test de l'UI ».

Rebase préalable sur `develop@fe0e53e` (#65 avait fait avancer la base) :
sans conflit, aucun recouvrement de fichiers, arbre `frontend/` identique bit
pour bit à l'original `6ed0087`.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 15:16:21 +02:00
24f5e85974 chore(ideai): carnet de #69 — validation live partielle et réserve du lot 3
État `.ideai/` du chantier client téléphone, séparé du code applicatif
conformément aux précédents `5ee25d1` / `8e481ae`.

- Carnet #69 : périmètre exact de la validation live utilisateur sur téléphone
  réel (lots 1 et 2 validés en réel via l'appairage puis le workspace ; lot 3 —
  `TerminalKeyBar` et invariant de focus — NON exercé), arbitrage Main
  autorisant le merge avec réserve écrite, et report de l'écart Playwright
  vers #63 plutôt que vers un ticket neuf.
- Faits de topologie mis à jour après rebase sur `develop@fe0e53e` : les SHA
  cités (`e22ea5b`/`8f15ad6`/`6ed0087`) n'existaient plus sur aucune branche.
- Journal des tâches de fond : complétions enregistrées.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 15:15:45 +02:00
f0f2f3b497 fix(frontend): retirer l'import vi inutilisé du test de la key bar (#69)
`npm run build` est `tsc --noEmit && vite build` : un import non utilisé
casse le build (TS6133), pas seulement le lint.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 15:13:22 +02:00
62ecefe1e8 feat(frontend): terminal pilotable au doigt sur téléphone (#69)
Lots 3 et 4 du ticket #69. Sans ça un agent CLI est indriveable depuis un
téléphone : le clavier virtuel n'a ni Esc, ni Tab, ni Ctrl, ni flèches, donc
on peut taper un prompt mais pas l'interrompre, compléter un chemin, sortir
d'un éditeur ou rappeler l'historique.

- `TerminalView` expose un `onReady(api)` optionnel (donc desktop inchangé,
  et inerte quand xterm ne monte pas). `api.send` passe par `term.input()` :
  le *même* chemin qu'une frappe réelle, donc le relais PTY, le comptage de
  lignes et la suspension du write-portal s'appliquent à l'identique. Écrire
  sur le handle aurait court-circuité le portal.
- `TerminalKeyBar` (web-only) : Esc/Tab/Ctrl-C/Ctrl-D/flèches en chips
  tactiles 44px, scroll horizontal. Chaque tap annule le déplacement de
  focus et refocalise xterm — sinon le clavier virtuel se referme à chaque
  touche.
- La cellule agent passe de `h-64` fixe (une letterbox d'~20 lignes) à
  `h-[60dvh]` sur téléphone, `sm:h-80` au-delà.
- Tests : séquences d'octets émises, préservation du focus, état désactivé
  avant montage de xterm, et garde de non-régression sur la frontière —
  le client web ne monte aucun layout-grid/split/dock desktop.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 15:13:22 +02:00
48b8853214 feat(frontend): shell web responsive pour viewport téléphone (#69)
Lots 1 et 2 du ticket #69 : rendre le client web (#13) utilisable sur un
téléphone. Le client web n'a jamais eu de docks ni de fenêtres flottantes —
il est déjà une colonne verticale unique — donc le lot 2 se réduit aux
rangées qui débordaient réellement à 360px.

- `100dvh` sur html/body/#root : `height: 100%` se résout sur le *large*
  viewport, donc la barre d'URL rétractable d'un navigateur mobile masquait
  le bas de l'app. Desktop inchangé (dynamic == large viewport).
- `viewport-fit=cover` + padding `env(safe-area-inset-*)` sur le header et
  le workspace : l'app peut peindre sous une encoche sans perdre ses
  contrôles. Le zoom reste libre (accessibilité).
- Padding responsive (`p-4 sm:p-6`) : 48px de gouttière sur 360px, c'était
  13% de la largeur.
- `AgentLiveRow` et la rangée de tâche de fond empilent leurs contrôles sur
  téléphone (nom / badges / actions) et retrouvent leur ligne unique dès
  `sm` — à 360px les boutons Cancel+Retry ne tenaient pas.
- Code d'appairage : `inputMode="numeric"`, pas d'autocapitalisation.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 15:13:22 +02:00
fe0e53ec59 Merge feature/ticket65-idea-serve-headless into develop (#65)
Intègre le serveur headless `idea-serve` : le cœur (use cases, DTO, events)
devient partagé entre deux driving adapters, le desktop Tauri et le crate
`web-server` autonome, sans dépendance GUI.

Vert avant merge : `cargo test -p backend` 41 · `-p web-server` 55 ·
`-p app-tauri` 35, 0 échec, ré-exécuté sur la branche. Invariant headless
vérifié (`ldd idea-serve` sans webkit/gtk/tauri) et validation live utilisateur
du serveur (démarrage, SPA servi, contrôle d'origine strict, accès distant).

Débloque #68 (activer le serveur depuis le desktop, via `run_embedded`) et #66
(Docker).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 15:02:28 +02:00
5ee25d1ef6 chore(ideai): état d'orchestration du sprint serveur headless (#65, #68-#70)
État durable de `.ideai/` accumulé pendant le chantier `idea-serve`, séparé du
code applicatif conformément aux précédents `8e481ae` / `ad1f225`.

- Tickets : #13 clôturé (server/client mode livré), #65 passé en QA avec son
  carnet de chantier complet (arbitrages Architect sur le propriétaire canonique
  des DTO, structure livrée, vérif QA, incident de topologie et sa leçon).
  #64/#66/#67 rattachés au sprint. Nouveaux tickets #68 (activer le serveur
  depuis le desktop, dépend de #65), #69 (adaptabilité client téléphone, en QA)
  et #70 (gestion des modèles locaux llama.cpp).
- Mémoire : note `web-client-is-single-column-no-desktop-shell` — le client web
  n'a pas de shell desktop, à lire avant tout cadrage responsive sur cette
  surface.
- Journal des tâches de fond : complétions enregistrées.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 15:02:14 +02:00
4f57e5a0db chore(gitignore): ignorer la sortie du build web frontend/dist-web (#65)
Le build web (`VITE_TRANSPORT=http`) que sert `idea-serve` produit
`frontend/dist-web/`, remonté comme non suivi car la règle existante n'ancrait
que `frontend/dist/`. C'est de la sortie de build (~1 Mo, rebuildable depuis les
sources) : même classe que `dist/`, elle n'a pas sa place dans l'historique.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 15:01:40 +02:00
0e15482ce2 feat(web-server): extraire le serveur headless idea-serve du binaire Tauri (#65)
Sort le serveur HTTP/WS de `app-tauri` vers un crate `web-server` autonome,
exposant le binaire `idea-serve` qui sert le client web sans aucune dépendance
GUI. Le cœur (use cases, DTO, events) devient partagé entre deux driving
adapters : le desktop Tauri et le serveur headless.

Structure :
- `crates/web-server` : lib + bin `idea-serve`, consomme `backend::{dto, events}`.
- `crates/backend` : `dto.rs` et `events.rs` deviennent le propriétaire canonique
  des DTO/events transport-neutres (arbitrage Architect : pas de crate contrat
  dédié, `backend` est déjà le composition root transport-neutre).
- `crates/app-tauri` : `dto.rs` réduit à un shim de ré-export, `events.rs` réduit
  au relais Tauri (souscription au bus + emit), `server.rs` vidé au profit du
  crate partagé.
- `Cargo.toml`/`Cargo.lock` : `web-server` ajouté aux membres du workspace.

Frontière respectée : les DTO de `backend` ne tirent ni Tauri, ni HTTP/WS, ni
Axum/Hyper, ni UI ; `domain`/`application` n'en dépendent pas. Le frontend est
inchangé (`git diff 506d589...HEAD -- frontend` vide).

`web_server::run_embedded(...)` est le point d'extension prévu pour #68 (le
desktop consommera `web-server` comme lib plutôt que d'en forker le serveur).

QA (exécution réelle, re-vérifiée avant merge) :
- `cargo test -p backend` 41 passed · `-p web-server` 55 passed · `-p app-tauri`
  35 passed, 0 échec.
- Invariant headless : `ldd target/debug/idea-serve` ne tire aucun
  webkit/javascriptcore/gtk/gdk/soup/tauri/wry, là où `app-tauri` les tire bien.
- Validation live utilisateur : `idea-serve` démarre, sert le SPA, le contrôle
  d'origine strict tient, accès distant OK via reverse proxy.
- Les 10 échecs `openai_compat` de `cargo test --workspace` sont préexistants sur
  `506d589` (bind réseau interdit par la sandbox), hors périmètre.

Squash de `82e8e77` (commit de sûreté « état intermédiaire non figé », qui
rapatriait le travail réalisé par erreur sur la branche de #69) et de `ddbea7b`
(déduplication des DTO events, comblant l'écart annoncé par le premier). Les deux
n'avaient de sens qu'ensemble : ce commit fige le contrat que le premier laissait
explicitement ouvert. Arbre identique bit pour bit à `ddbea7b` ; historique
d'origine conservé sur `backup/ticket65-pre-squash-ddbea7b`.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 15:01:18 +02:00
506d58956b Merge feature/server-client-packaging into develop (#13)
Transport HTTP/WS et surface web du ticket #13, validé par l'utilisateur en
lancement Desktop (comportement conforme).

Contenu : endpoint PTY WebSocket authentifié et relais live-state/background
côté serveur (idea --serve), client web read-only, xterm.js sur WebSocket avec
reconnexion et scrollback, surfaces agent et live web, service same-origin de
dist et durcissement (logout, logs de sécurité, static hardening).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 10:32:46 +02:00
8e481aed69 chore(ideai): état d'orchestration du sprint #13 (transport HTTP/WS + surface web)
Versionne l'état runtime IdeA produit pendant le sprint #13 : store de
tickets (dont les nouveaux #55 à #67), compteur et index, notes de mémoire
projet des lots F0 à F5, et journal des tâches de fond.

Séparé du code applicatif conformément à la convention du dépôt
(cf. ad1f225, a244f32) : métadonnée d'orchestration last-writer-wins,
sans impact sur le build.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 10:32:39 +02:00
c246875f6d fix(frontend): connecter le WS live sur /api/ws conforme au contrat (#13)
Le client live visait /ws/live alors que le serveur expose /api/ws : la
connexion échouait et la reconnexion bouclait en permanence. Chemin corrigé
et extrait en constante WS_PATH, avec deux tests de non-régression sur
l'URL construite.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 09:14:37 +02:00
de9c90966d fix(frontend): binder le fetch global à globalThis (pairing Firefox) (#13)
Firefox exige que fetch soit appelé sur Window : passer la référence nue
`fetch` en dépendance déclenchait « 'fetch' called on an object that does
not implement interface Window » au pairing. Nouveau helper defaultFetch()
qui binde globalThis.fetch, utilisé par webSession.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 08:47:00 +02:00
c9ce3d7c4e fix(server): aligner app-data-dir sur l'identifier desktop + corriger doc build web (#13)
default_app_data_dir aligné sur l'identifier tauri app.idea.ide, avec
précédence IDEA_APP_DATA_DIR > XDG_DATA_HOME > HOME. Log stderr
`idea --serve: app data dir = <path>` au démarrage et test de précédence.
Doc build web corrigée (VITE_TRANSPORT=http npx vite build + npm au lieu
de pnpm), section app-data-dir et avertissement double-writer desktop/serve.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 08:39:22 +02:00
6117177957 feat(frontend): polish web (logout, 401→pairing, reconnexion globale) (#13)
Flow logout : POST /api/logout puis retour à l'écran de pairing et
déconnexion du live. 401 renvoie au pairing sans boucle. Bannière de
reconnexion couvrant le cas live-only et le serveur indisponible.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 08:23:11 +02:00
d538808a0d feat(server): servir dist same-origin + durcissement (logout, logs sécurité, static hardening) (#13)
Sert le bundle web (dist/) en same-origin via --web-root / IDEA_WEB_ROOT
ou le web/ packagé. serve_static durci : anti path-traversal, typage MIME,
X-Content-Type-Options nosniff, CSP, fallback SPA. Ajoute POST /api/logout
qui révoque la session HTTP + WS, et une journalisation sécurité via
SecurityLogger. Documente le déploiement remote (dev local, packaging web/,
reverse proxy HTTPS).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 08:10:31 +02:00
dd1d083a1a feat(frontend): surfaces live web (workstate live, background, inbox, reconnect) (#13)
Lot F5 du chantier server/client mode : le client web consomme les frames
event.domain (B7) pour animer ses surfaces live.

- webLive.ts : consommation du flux event.domain (workstate, background,
  inbox).
- useLiveReconnect.ts : reconnexion du flux live.
- wsLiveClient.ts / index.ts : câblage du transport live.
- WebWorkspace.tsx : surfaces live branchées.
- Tests : WebWorkspaceLive.test.tsx, wsLiveClientReconnect.test.ts,
  WebApp.test.tsx.

Validé : frontend 753 tests verts, desktop non régressé.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-15 23:37:02 +02:00
1bc5217dbc feat(server): relais live-state + actions background via web (event.domain, allowlist) (#13)
Lot B7 du chantier server/client mode : le serveur --serve relaie l'état
live et les tâches de fond au client web.

- Relais du bus domaine en frames event.domain, queue bornée avec drop,
  exclusion de PtyOutput.
- Allowlist étendue : list_background_tasks (read) + cancel_background_task
  / retry_background_task (actions), sous auth.
- 49 tests server (fan-out, drop sur queue pleine, relais de complétion
  background, exclusion PtyOutput, actions allowlist + auth). Clippy propre.

Validé : app-tauri 292+ tests verts, backend 28, cœur backend agnostique,
desktop non régressé. Réserve connue : le fan-out socket réel relève d'une
validation live hors sandbox.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-15 23:36:50 +02:00
5254f16095 feat(frontend): surface agent web sur WebSocket (cellule agent) (#13)
Lot F4 du chantier server/client mode : le client web expose une cellule
agent branchée sur le PTY WebSocket, en face de agent.launch (B6).

- wsLiveClient.ts : launchAgent sur le transport WebSocket.
- streamGateways.ts : gateway agent alignée sur le contrat serveur B6.
- WebAgentCell.tsx : cellule agent web, câblée dans WebWorkspace et index.
- Tests : agentGateway.test.ts, WebApp.test.tsx.

Validé : frontend 749 tests verts, contrat B6↔F4 aligné (aucun écart de
frame), desktop non régressé.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-15 23:17:24 +02:00
6391d1c75a feat(server): agents CLI via le PTY WebSocket sur idea --serve (#13)
Lot B6 du chantier server/client mode : le serveur --serve permet de lancer
et piloter un agent CLI à travers le PTY WebSocket B5.

- Frame WS agent.launch → ack terminal.attached avec assignedConversationId.
- Réutilise LaunchAgent + TerminalSessions + sink WS B5, réattache sans
  respawn, singleton AGENT_ALREADY_RUNNING, structured → UNSUPPORTED.
- 42 tests server (launch/reattach/singleton/structured), tests flaky
  stabilisés. Clippy server.rs propre.

Validé : app-tauri 286 tests verts, backend 28, contrat B6↔F4 aligné
(aucun écart de frame), desktop non régressé. Réserve connue : le
round-trip socket réel relève d'une validation live hors sandbox.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-15 23:17:11 +02:00
7487902ddb feat(frontend): xterm.js sur WebSocket avec reconnexion et scrollback (#13)
Lot F3 du chantier server/client mode : le client web branche xterm.js sur
le terminal distant via WebSocket, en face de l'endpoint PTY B5.

- wsLiveClient.ts : transport WebSocket du terminal avec reconnexion.
- streamGateways.ts : gateway terminal (open/attach/data/resize/close).
- frames.ts : frames PTY alignées sur le contrat serveur B5.
- Tests : terminalGateway.test.ts, wsLiveClientReconnect.test.ts.

Validé : frontend 743 tests verts (F3 ciblé 12), cohérence des frames
B5↔F3 confirmée, desktop non régressé.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-15 18:09:25 +02:00
917be995a4 feat(server): endpoint PTY WebSocket authentifié sur idea --serve (#13)
Lot B5 du chantier server/client mode : le serveur --serve expose le
terminal distant via un endpoint WebSocket, préalable au client xterm (F3).

- Handshake WebSocket RFC 6455 fait main, sans nouvelle dépendance.
- Auth de l'upgrade par cookie de session + Origin strict.
- Frames PTY (open/attach/close/ping), réattache, scrollback, backpressure.
- 37 tests server dont les refus de sécurité et les handlers
  open/attach/close/ping. Clippy propre (result_large_err corrigé).

Validé : app-tauri 277 tests verts, backend 28, cohérence des frames
B5↔F3 confirmée, desktop non régressé. Réserve connue : le round-trip
socket réel relève d'une validation live hors sandbox.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-15 18:09:14 +02:00
e457152c66 Merge feature/ticket13-server-client-mode into develop (#13)
Premier incrément livrable du chantier server/client mode (B0→B4/F2) :
cœur backend commun extrait hors Tauri, sink de stream agnostique, serveur
HTTP sécurisé idea --serve (pairing + cookie de session, allowlist
read-only), et client web read-only (pairing, liste, ouverture, snapshot).

Desktop inchangé ; mode web opt-in via VITE_TRANSPORT="http". PTY WebSocket
(B5) + xterm (F3) reportés à la 2e vague. Incrément VERT de bout en bout.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-15 13:25:59 +02:00
e500e31663 feat(frontend): client web read-only pairing + snapshot état (#13)
Lot F2 du chantier server/client mode : client web read-only complétant le
premier incrément livrable — pairing, liste des projets, ouverture et
snapshot de l'état, sans PTY.

- frontend/src/adapters/http/webSession.ts : session web (pairing/cookie).
- frontend/src/features/web : PairingScreen, WebWorkspace, WebApp, index.
- Câblage main.tsx et adaptations httpInvoker.ts / index.ts (cas 401).
- Tests : webSession.test.ts, WebApp.test.tsx, cas 401 dans
  httpInvoker.test.ts.

Validé : frontend 736 tests verts, build vert, garde no-direct-invoke
verte, contrat B4↔F2 aligné, desktop non régressé.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-15 13:21:35 +02:00
fa353f6c0b feat(server): allowlist read-only (get_project_work_state, open_project read-only) (#13)
Lot B4 du chantier server/client mode : extension read-only de l'allowlist
du serveur --serve pour clôturer le premier incrément livrable (sans PTY).

- open_project exposé en read-only via resolve_project_readonly.
- get_project_work_state ajouté à l'allowlist.
- 4 nouveaux tests.

Validé : cargo check --workspace vert, app-tauri 265 tests verts (dont les
4 tests B4), contrat B4↔F2 aligné (list_projects/open_project/
get_project_work_state), desktop non régressé.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-15 13:21:28 +02:00
4ed0b168d2 feat(server): sous-commande idea --serve avec serveur HTTP sécurisé pairing+cookie (#13)
Lot B3 du chantier server/client mode : socle serveur sécurisé exposant le
cœur backend en mode client/serveur, sans PTY (reporté B5).

- crates/app-tauri/src/server.rs : sous-commande --serve, serveur HTTP
  sécurisé — /api/invoke sur allowlist, /api/pair → cookie de session,
  Origin strict, refus du secret en query, gate de bind. 16 tests dont les
  2 refus de sécurité (pairing_rejects_wrong_code,
  invoke_rejects_invalid_session_cookie).
- crates/app-tauri/src/lib.rs : câblage de la sous-commande --serve.
- crates/app-tauri/src/commands.rs : adaptations.
- crates/app-tauri/Cargo.toml : deps bytes/cookie/http/http-body-util,
  feature tokio net. Cargo.lock synchronisé.

Validé : cargo check --workspace vert, app-tauri 267 tests verts, cœur
backend agnostique confirmé, desktop non régressé.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-15 13:06:40 +02:00
e0cdb4aa56 feat(frontend): adapter web HTTP+WebSocket derrière les ports (#13)
Lot F1 du chantier server/client mode : nouvel adaptateur web branché
derrière les ports d'invocation et de flux live, permettant au frontend de
dialoguer avec le backend via HTTP + WebSocket en mode client/serveur. Le
mode desktop (Tauri IPC) reste inchangé.

- frontend/src/adapters/http : invoker HTTP, client live WebSocket, gateways
  request/response et stream, frames, garde unsupported (7 fichiers + 2 tests).
- frontend/src/app : câblage DI (di.tsx) et son test, typage vite-env.d.ts.

Validé : build vert, garde no-direct-invoke verte, 724 tests verts,
desktop inchangé.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-15 12:50:38 +02:00
c8fef2a76a refactor(backend): abstraire le sink de stream hors de tauri::ipc::Channel (#13)
Lot B2 du chantier server/client mode : le cœur backend émet désormais ses
flux via une abstraction de sink agnostique, sans dépendre directement de
tauri::ipc::Channel, préalable au futur serveur web + PTY WebSocket.

- crates/backend : abstraction de sink (stream.rs) câblée dans lib.rs.
- crates/app-tauri : implémentation Tauri du sink (stream.rs) et adaptation
  des surfaces lib.rs, pty.rs, chat.rs.
- Nettoyage clippy des 2 warnings B2.

Validé : cargo check --workspace vert, tests backend/app-tauri verts,
cœur agnostique Tauri, clippy B2 propre.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-15 12:50:29 +02:00
955db79e97 refactor(backend): extraire le cœur backend commun hors Tauri (#13)
Lot B1 du chantier server/client mode : création de la crate `backend`
qui héberge le cœur commun (endpoint MCP, outils OpenAI) indépendant de
Tauri, préalable au futur serveur web + PTY WebSocket.

- crates/backend : nouvelle crate (lib.rs, mcp_endpoint.rs, openai_tools.rs).
- crates/app-tauri : câblage sur la crate backend (state.rs, mcp_bridge.rs,
  Cargo.toml, tests/orchestrator_wiring.rs).
- Cargo.toml / Cargo.lock racine : ajout de la crate au workspace.

Validé : cargo check --workspace vert, tests backend/app-tauri verts.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-15 09:50:17 +02:00
5505acc1f6 docs(ticket13): inventaire transport backend et frontend (B0)
Lot B0 du chantier server/client mode : cartographie des surfaces de
transport existantes, préalable à l'extraction du cœur backend commun.

- docs/ticket13-b0-backend-transport-inventory.md : inventaire backend.
- docs/ticket13-f0-frontend-transport-inventory.md : inventaire frontend.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-15 09:50:10 +02:00
ebad5ff9f2 Merge feature/ticket60-ticket-assistant-no-reply into develop (#60)
Rendre visible l'échec « aucune réponse » de l'assistant de ticket :
stream sans Final ou Final vide → ReplyChunk::Error terminal visible,
plus jamais de tour muet. Backend + frontend, tests verts.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-15 08:48:04 +02:00
18e6bedb8b Merge feature/ticket55-model-warmup-deadline into develop (#55)
Deadline de warmup configurable pour le cold-start llama.cpp.
Tests verts (domain/application/infrastructure + dto app-tauri).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-15 08:47:59 +02:00
f7cae4c0a8 fix(model-server): deadline de warmup configurable pour le cold-start llama.cpp (#55)
Corrige la régression high « Error on loading local model » : le premier chargement
du serveur modèle local (cold-start llama.cpp) dépassait la fenêtre de readiness et
échouait. Le warmup dispose désormais d'un deadline par défaut de 600 s, surchargable
par config optionnelle `warmup_deadline_secs` (validée dans [30, 1800]).

- domain: champ `warmup_deadline_secs: Option<u64>` + validation de borne
- application: policy de readiness effective (défaut 600 s, override par config)
- app-tauri: DTO `warmupDeadlineSecs`
- infrastructure: application de la deadline effective au warmup

Verdict QA (vert) : domain 252, application 81 + 22 model_server, app-tauri
dto_model_servers 6, infrastructure model_server 2, build OK. Contrat readiness
couvert sur ports mockés.
Caveat : le cold-start end-to-end réel (llama-server) sort du sandbox de test ->
vérification manuelle utilisateur restante, non couverte par les tests unitaires.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-15 08:41:44 +02:00
2f7f111545 fix(ticket-assistant): rendre visible l'échec « aucune réponse » de l'assistant de ticket (#60)
Introduit un variant terminal `ReplyEvent::Error { message }` (domain/ports)
propagé jusqu'au chat : l'adapter OpenAI-compat récupère `reasoning_content`
quand `content` est vide, et un `Final` vide est converti en `Error` visible
plutôt qu'un tour silencieux qui pend. Le front (`ReplyChunk` + useTicketAssistant)
rend ce message d'erreur dans la cellule.

- domain: variant `ReplyEvent::Error`, bras non terminal (readiness, structured drain)
- infra/session: parse `reasoning_content` (delta/completion), fallback visible
- app-tauri: mapping ReplyEvent::Error -> ReplyChunk::Error, Final vide -> Error
- frontend: ReplyChunk `error`, rendu dans useTicketAssistant (+ test .test.tsx)

NB: commit sur la feature branch, PAS un merge. #60 reste inProgress.
Les 10 tests `cargo test -p infrastructure --lib session` échouent SOUS SANDBOX
uniquement (bind loopback 127.0.0.1:0 interdit -> Os PermissionDenied), pas une
régression : revérification hors-sandbox requise avant tout merge vers develop.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-15 08:32:59 +02:00
ce5aa2811c Merge feature/ticket2-ptyport-wait-decouple-output into develop (#2)
PtyPort::wait/try_wait ajoutés au port figé (exit status mémorisé, idempotent) ;
le runner de tâches de fond détecte la fin via wait au lieu de l'EOF du drain
output, découplant cycle de vie du process et flux de sortie. Fakes PtyPort du
workspace complétés. Tee live UI hors périmètre (#58). QA vert.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 23:42:48 +02:00
62b71776f5 fix(background-task): découpler la détection de fin de tâche du drain output PTY (#2)
Le runner de tâches de fond détectait la fin d'un process via l'EOF du drain de
sortie PTY, couplant le cycle de vie du process au flux d'output. Un output
encore ouvert (ou drainé ailleurs) pouvait masquer ou retarder la détection de
fin.

Ajoute wait/try_wait au port figé PtyPort :
- wait : bloquant, rend un ExitStatus idempotent ;
- try_wait : non bloquant, rend Option<ExitStatus> ;
- exit status mémorisé pour garder wait/try_wait/kill cohérents.
Implémentation dans PortablePtyAdapter (état d'exit mémorisé). Le
CommandBackgroundRunner détecte désormais la fin via pty.wait (select sur
cancel/deadline) au lieu de l'EOF du drain. Tous les fakes PtyPort du workspace
sont complétés en conséquence.

Le tee live UI reste hors périmètre (traité en #58). Aucun breaking IPC/front.

Tests : infrastructure/tests/background_task_runner.rs (nouveau) + pty_adapter.rs
verts, non-régression application/app-tauri OK (hors échecs réseau du sandbox).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 23:42:40 +02:00
c6e34483d3 Merge feature/ticket31-detectprofiles-parallel-probes into develop (#31)
Sondes de DetectProfiles::execute parallélisées (une tâche Tokio par candidat,
JoinHandle attendus dans l'ordre) : coût total ~1×timeout au lieu de N×800ms,
ordre de sortie déterministe préservé. QA vert 20/20.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 19:32:04 +02:00
2d7396a86b perf(agent): paralléliser les sondes de DetectProfiles::execute (#31)
Les sondes de détection de profils étaient exécutées séquentiellement, portant
le coût total au pire à N×800 ms (N × timeout par candidat).

Chaque candidat est désormais sondé dans une tâche Tokio dédiée (tokio::spawn),
les JoinHandle étant attendus dans l'ordre de création : le coût total tombe à
~1×timeout tout en préservant un ordre de sortie déterministe. Aucune dépendance
ajoutée, aucun changement de contrat.

Test : crates/application/tests/profile_usecases.rs (concurrence multi-thread +
ordre déterministe). profile_usecases 20/20, suite application verte.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 19:31:57 +02:00
51b5d07f35 Merge feature/ticket34-chatbridge-scrollback-bounded into develop (#34)
Scrollback de ChatBridge borné (double cap chunks + octets, drop par la tête)
pour stopper la croissance mémoire du buffer de replay. Aucun changement DTO.
QA vert 19/19.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 19:26:37 +02:00
b4b86cdc0e fix(chat): borner le scrollback de ChatBridge (#34)
Le scrollback de ChatBridge croissait sans limite, faisant enfler la mémoire sur
les conversations longues. Il sert de buffer de replay transport (reattach), pas
d'historique durable.

Introduit un double cap : MAX_CHAT_SCROLLBACK_CHUNKS=2000 et
MAX_CHAT_SCROLLBACK_BYTES=512 KiB. Un helper trim_scrollback, appelé après chaque
send_output, drop des chunks entiers par la tête tout en conservant l'ordre et
les chunks les plus récents. Doc de chat.rs corrigée pour refléter cette nature
de buffer borné.

Aucun changement de ReplyChunk / reattach_agent_chat / DTO. Tests : suite
chat_bridge 19/19.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 19:26:32 +02:00
63a7b6165f Merge feature/ticket20-ticketlist-ref-match-opaque-cursor into develop (#20)
ticket_list : matching exact du numéro/#ref dans la recherche texte + curseur
de pagination opaque et stable (anchor-based v1, rejet explicite des curseurs
invalides). DTO cursor inchangé (non-breaking UI). Tests #20 verts 7/7.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 19:20:49 +02:00
bd5d8d864a fix(tickets): matching exact du #ref et curseur de pagination opaque/stable pour ticket_list (#20)
Épurement de la dette de ticket_list sur deux axes :

Recherche texte — matching exact du numéro/#ref via parse_issue_search_ref,
court-circuité avant load_issue, sans matching par substring numérique
(« 1 » ne remonte plus « 12 », « 123 »…).

Pagination — curseur opaque et stable anchor-based au lieu d'un offset fragile :
token v1.<base64url-no-pad-json> encodant le tri + l'ancre {number, sortKey},
reprise strictement après l'ancre. Curseur legacy / invalide / de version
inconnue / avec sort divergent rejeté par une erreur explicite « Invalid
cursor ». Le DTO cursor reste String → non-breaking côté UI.

Fichiers : infrastructure/src/issues.rs, app-tauri/src/tickets.rs,
app-tauri/Cargo.toml (+ base64 0.22). Tests : issue_store_text_filter,
ticket_list_ 7/7 (anchor-based + rejets).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 19:20:40 +02:00
83e4df7626 Merge feature/ticket33-structured-routing-explicit into develop (#33)
Routage structuré vs PTY rendu explicite dans LaunchAgent
(StructuredRoutingMode) : erreur explicite au lieu du fallthrough silencieux
quand un profil structuré rencontre une factory non câblée. QA vert.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 19:08:32 +02:00
67101ba607 fix(agent): rendre explicite le routage structuré vs PTY dans LaunchAgent (#33)
Un profil structuré rencontrant une factory de session non câblée retombait
silencieusement sur pty.spawn (fallthrough du `if let`), masquant une erreur de
configuration au lieu de la signaler.

Remplace ce fallthrough par une intention explicite :
- nouvel enum StructuredRoutingMode { HumanPtyFallback, RequireStructured } sur
  LaunchAgent, posé via le builder with_structured_routing_mode ;
- le `if let` devient un `match` explicite (agent/lifecycle.rs) ; en mode
  RequireStructured, un profil structuré sans factory câblée retourne
  AppError::Process("structured profile requires structured session factory")
  au lieu de tomber sur pty.spawn.

Composition root (app-tauri/src/state.rs) : launcher humain = HumanPtyFallback,
launcher orchestrateur = RequireStructured, wake background rebranché sur
orchestrator_launch_agent.

Tests : agent_lifecycle.rs (4 branches de routage) + non-régression
agent_wake/structured_launch_d3. Crate application verte.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 19:08:23 +02:00
e24bb5f1f4 Merge feature/ticket56-agent-selector-visible-elsewhere into develop (#56)
Le sélecteur d'agent de LayoutGrid dérive « visible ailleurs » du layout
courant : un agent live non réellement affiché redevient sélectionnable, sans
tuer la session. QA vert 706/706.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 18:56:40 +02:00
4099b0d1c4 fix(layout): rendre resélectionnable un agent live non réellement affiché (#56)
Le sélecteur d'agent de LayoutGrid désactivait un agent en se fondant sur le
seul liveAgents.nodeId : un agent live dont l'ancienne cellule affiche désormais
un autre agent restait grisé (« visible ailleurs ») alors qu'il n'était plus
affiché nulle part, donc impossible à resélectionner.

La dérivation « visible ailleurs » s'appuie maintenant sur le layout courant
(feuille visible ≠ cellule courante ET leaf.agent === candidate). Un agent live
dont l'ancienne cellule montre un autre agent redevient sélectionnable dans une
autre cellule ; la session n'est jamais tuée (attachLiveAgent conservé). Le prop
mort visibleNodeIds est retiré du threading.

Tests : frontend/src/features/layout/singletonAgent.test.tsx. Suite frontend
verte 706/706.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 18:56:34 +02:00
fd5c8932ca Merge feature/ticket55-model-server-readiness into develop (#55)
Fiabilisation de la readiness au démarrage d'un serveur modèle local
(llama.cpp) : deadline de warmup longue, distinction vivant-en-warmup /
process mort. QA vert 20/20.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 18:43:54 +02:00
141c13dabb fix(model-server): fiabiliser la readiness au démarrage d'un serveur modèle local (#55)
Le serveur modèle local (llama.cpp) était tué après ~5 s par un timeout de
readiness prématuré, alors que le modèle était encore en warmup (chargement en
RAM/VRAM). Résultat : « Error on loading local model » alors que le process
était vivant et en train de démarrer normalement.

Introduit une deadline de warmup longue configurable (~120 s via
ReadinessPolicy) qui distingue un process « vivant en warmup » d'un process
« mort » :
- Ready                → succès immédiat
- Unreachable + Running → continuer d'attendre (warmup en cours)
- Unreachable + Exited  → échec rapide (process mort, inutile d'attendre)
- deadline atteinte     → stop + Timeout

Tests (crates/application/tests/model_server.rs) : warmup lent, exit pendant le
warmup, deadline atteinte, plus la régression adaptée. 20/20 verts, crate
application verte.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 18:43:46 +02:00
e0ee24e3b5 Merge feature/ticket54-model-download-progress into develop (#54)
Stretch B2/F2 : progression fine du téléchargement du modèle llamacpp,
par-dessus le MVP (B1/F1) déjà intégré. Tests verts (application +
infrastructure + vitest, tsc clean).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 10:37:33 +02:00
ad1f2257e6 chore(ideai): état d'orchestration du sprint #54 (progression téléchargement)
Métadonnée runtime IdeA : tickets, sprints, mémoire et background-tasks
mis à jour au fil du sprint de progression fine du téléchargement (#54).
Séparé du code de feature (last-writer-wins, état non applicatif).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 10:37:23 +02:00
2183dfd291 feat(model-server): progression fine du téléchargement du modèle llamacpp (#54)
Stretch B2/F2 de #54, par-dessus le MVP déjà mergé (B1/F1).

Backend : le port de téléchargement HF publie une progression débouncée
(bytes reçus / total, pourcentage) via le stream de statut du serveur
modèle, avec gestion du total inconnu (pas de faux %), du cache hit,
de l'annulation et du timeout.

Frontend : l'overlay plein-cellule de préparation du serveur affiche la
progression réelle (barre, %, octets, source) en mappant le fil de
statut, avec la règle « pas de faux % » quand le total est inconnu.

Tests : application + infrastructure (téléchargement débouncé, cancel,
timeout, cache hit, total inconnu) et vitest (overlay + formatage pur).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 10:37:14 +02:00
bd335c3a1c Merge feature/ticket54-llamacpp-model-download into develop (#54)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 23:14:13 +02:00
fe7ed0aa20 feat(model-server): afficher le téléchargement du modèle llamacpp au démarrage (#54)
Ajoute un handle du téléchargement des modèles lors du démarrage de
llamacpp : le domaine et l'application émettent la progression de
téléchargement du modèle, relayée en événement côté app-tauri, et l'UI
l'affiche via un badge de lancement et un overlay de cellule pendant que
le serveur de modèle démarre.

Backend (B1) : progression de téléchargement dans domain/application,
relais d'événement app-tauri, couverture de tests.
Frontend (F1) : modelServerLaunch, badge et overlay LayoutGrid, tests.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 23:14:05 +02:00
c67ec4f7bd Merge feature/ticket44-firstrun-keep-profile-info into develop (#44)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 22:53:58 +02:00
8cdc44de6e feat(first-run): conserver les infos du profil courant à l'édition (#44)
Extrait la logique de dérivation des entrées du wizard dans un module
dédié `wizardEntries` afin de préserver les informations du profil
courant lors de l'ouverture de l'affichage d'édition des profils, au
lieu de repartir d'un état vide. Couvre le comportement par des tests
unitaires (wizardEntries + FirstRunWizard).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 22:53:46 +02:00
76560ab101 Merge feature/ticket50-open-windows-menu-state into develop
Ticket #50 : commande backend `list_open_view_windows` + consommateur
frontend qui réconcilie l'état du menu Panneaux avec les fenêtres
détachées réellement ouvertes. Validé QA vert (frontend
typecheck+build+677 tests ; backend cargo check/build + 7 tests
view_window).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 18:15:09 +02:00
b4a01e0ae9 fix(view-windows): réconcilier l'état des fenêtres détachées au boot (#50)
Branche le consommateur frontend sur la commande backend
`list_open_view_windows` : le port window expose la liste des fenêtres
de panneaux détachées réellement ouvertes côté OS, l'adaptateur Tauri
(et son double mock) l'implémente, et `ProjectsView` réconcilie le
placement des vues au démarrage à partir de ce snapshot au lieu de
supposer un état. Couvre `viewPlacement` et la réconciliation par des
tests dédiés.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 18:14:45 +02:00
c1051ce2f5 Merge feature/ticket52-add-project-button-tabs into develop
Ticket #52 : le bouton « + » d'ajout de projet est collé aux onglets
(retrait des `flex-1`). Validé QA vert (typecheck + build + 665 tests).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 18:04:24 +02:00
f7f56e8583 fix(projects): coller le bouton "+" aux onglets de projet (#52)
Retire les utilitaires `flex-1` sur la liste d'onglets et sur le
placeholder « No open tabs. » : le conteneur ne pousse plus la zone
d'onglets sur toute la largeur, si bien que le bouton d'ajout de projet
« + » vient directement à la suite des onglets au lieu d'être repoussé à
l'extrémité droite de la barre.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 18:04:16 +02:00
ea7a98be03 Merge chore/fmt-agent-lifecycle into develop
Applique rustfmt sur agent_lifecycle.rs pour que develop repasse
`cargo fmt --check`. Fix de formatage pur, aucun changement de comportement.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 18:01:14 +02:00
7ddf4d46b9 chore(fmt): appliquer rustfmt sur agent_lifecycle.rs
Reformate `launch_opencode_omits_api_key_when_profile_has_none` selon
rustfmt (le fichier committé échouait `cargo fmt --check`). Aucun
changement de comportement, purement du formatage.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 17:59:26 +02:00
afbf315e97 feat(view-windows): exposer list_open_view_windows pour l'état du menu
Ajoute la commande Tauri `list_open_view_windows` qui retourne un
`ViewWindowSnapshot` (panel, label, visible) par fenêtre de panneau
détachée, avec le parseur `view_panel_from_window_label` (labels stables
et legacy suffixés du project id). Enregistre la commande dans le
handler. Backend seul pour le ticket #50 ; pas encore de consommateur
frontend.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 17:59:15 +02:00
9326a4897a chore(memory): nettoyer les notes transitoires et supersédées (#49)
Suppression de 31 notes de mémoire projet devenues transitoires
(checkpoints, plans de test datés, findings résolus) ou supersédées, et
remise en parité de l'index MEMORY.md (52 entrées = 52 fichiers).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 13:20:07 +02:00
8bbd8d3d68 Merge feature/ticket30-session-limit-handle-main into develop
Fix du handle de limite de session sur le chemin direct (#30) + émission
AgentRateLimited sur le chemin délégué (#7/F2). QA verte.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 13:19:46 +02:00
225890b57a fix(session-limit): émettre AgentRateLimited sur le chemin délégué (#7)
Sur le rendez-vous délégué (idea_ask_agent), quand la cible touchait sa
limite de session, l'événement AgentRateLimited n'était pas émis : l'écart
backend documenté (ticket #7/F2) laissait la surface UI sans signal de
limite pour la cible déléguée.

Le service orchestrateur relaie désormais la limite de la cible vers le
service de limite de session, fermant l'écart en cohérence avec le chemin
direct (#30).

Couverture QA (sortie réelle) : orchestrator_service 63 passed,
session_limit_service 15 passed, session_limit_t4 7 passed,
cargo test -p application 0 failed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 13:19:21 +02:00
9430c65050 fix(session-limit): brancher le handle de limite sur le chemin direct (#30)
Le handle de limite de session ne se déclenchait pas quand un agent
directement adressé (dont Main) touchait sa propre limite : le ReplyEvent
::RateLimited du chemin structuré direct n'était pas relayé au service de
limite.

On tap désormais ReplyEvent::RateLimited dans le registre terminal vers
SessionLimitService::on_rate_limited, qui émet AgentRateLimited puis
AgentResumeScheduled et arme la reprise auto annulable, exactement comme le
chemin délégué.

Couverture QA (sortie réelle) : structured_registry_d1 12 passed,
session_limit_wiring 6 passed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 13:19:11 +02:00
631dd4eccf Merge feature/ticket46-project-tab-add-button into develop
fix(projects): rendre visible le bouton + d'ajout d'onglet projet (#46)

Dernier ticket du sprint « Gestion des bugs » (#48, #45, #27, #47, #46).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 12:42:38 +02:00
b152e33b60 fix(projects): rendre visible le bouton + d'ajout d'onglet projet (#46)
Le bouton + de la barre d'onglets projets était invisible (pas de variant
d'affichage). Il est désormais rendu en permanence via un variant secondary,
avec aria-pressed et title pour l'accessibilité, permettant d'ajouter un
projet en onglet.

Couvert par un nouveau test (ProjectTabs.test.tsx).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 12:42:31 +02:00
0e594adaf3 Merge feature/ticket47-panel-only-windows into develop
fix(windows): restauration panel-only des fenêtres détachées suivant le projet en focus (#47)

Backend + frontend : fenêtres/panneaux détachés restaurés en mode panel-only
(sans project_id figé), suivant le projet en focus de la fenêtre principale
via l'event focused-project.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 12:37:56 +02:00
221cc8be78 fix(windows): fenêtres de panneau détachées suivent le projet en focus côté UI (#47)
Partie frontend. Ajoute un adaptateur focusedProject et un port dédié : la
ViewWindow détachée n'est plus liée à un project_id figé, elle s'abonne à
l'event focused-project émis par la fenêtre principale et affiche le panneau
du projet courant. ProjectsView propage le focus ; le détachement crée une
fenêtre panel-only. Couvert par les tests window/ViewWindow/focusedProject/
ProjectsView.focus.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 12:37:45 +02:00
6387fac34f fix(windows): restauration panel-only des fenêtres détachées suivant le projet en focus (#47)
Partie backend. Les fenêtres/panneaux détachés étaient restaurés avec un
project_id figé au moment du détachement, si bien qu'ils restaient collés à
un projet mort ou incohérent après redémarrage. Ils sont désormais restaurés
en mode panel-only, sans project_id figé, et suivent le projet en focus de la
fenêtre principale via un event focused-project exposé par la couche fenêtre.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 12:37:25 +02:00
1e0cb16ead Merge feature/ticket27-ticket-assistant-mcp-tools into develop
fix(ticket-assistant): édition de ticket via les tools MCP idea_ticket_* (#27)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 09:10:31 +02:00
8570adb8e0 fix(ticket-assistant): édition de ticket via les tools MCP idea_ticket_* (#27)
L'assistant IA d'édition de ticket éditait les fichiers du ticket en direct,
hors de tout contrôle. Il passe désormais par les tools MCP idea_ticket_* :
préparation d'un environnement structuré dédié et policy d'enforcement scopée
au ticket courant, de sorte que l'assistant ne peut agir que sur son ticket
via la surface MCP plutôt que sur le système de fichiers.

Couvert par de nouveaux tests QA (mcp_server, assistant_context_store).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 09:10:23 +02:00
e54ffae0c3 Merge feature/ticket45-model-server-singleflight into develop
fix(model-server): singleflight au démarrage du serveur de modèle local (#45)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 08:52:49 +02:00
3fff3402ec fix(model-server): singleflight au démarrage du serveur de modèle local (#45)
Corrige la race « port_occupied:8080 » au démarrage OpenCode/model server :
plusieurs demandes concurrentes tentaient chacune de lancer le serveur de
modèle local, provoquant un conflit de port. Le démarrage est désormais
sérialisé en singleflight — une seule tentative de lancement partagée entre
les appelants concurrents.

Couvert par un nouveau test de concurrence (cargo test -p application vert :
81 unit + 9 model_server).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 08:52:43 +02:00
f24f8f12aa Merge feature/ticket48-cell-error-banner into develop
fix(layout): bandeau d'erreur cellule au-dessus des boutons de contrôle (#48)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 08:42:23 +02:00
e64c0b7840 fix(layout): bandeau d'erreur cellule au-dessus des boutons de contrôle (#48)
Corrige la superposition z-index dans LeafView : le bandeau d'erreur de
cellule passait sous les boutons de contrôle, rendant le message illisible.
Le voile d'annonces ciblées est réaligné en conséquence.

Couvert par un nouveau test de layering (128/128 frontend au vert QA).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 08:42:13 +02:00
1331c5b2c2 Merge feature/ticket40-persist-restore-windows into develop
Persistance et restauration des fenêtres au redémarrage (#40).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 08:00:25 +02:00
2eb51d3335 feat(windows): persistance et restauration des fenêtres au redémarrage (#40)
Persiste l'état des fenêtres (layout/position) et le restaure au
relancement de l'application. Découpage hexagonal :
- domaine : modèle et port d'état des fenêtres (layout, ports)
- application : use cases de persistance/restauration
- infrastructure : store window_state (adapter de persistance)
- présentation : câblage app-tauri (state, commands, lib)
Couvert par des tests ciblés domaine/application/infrastructure.

Depend de #39 (fermeture des fenêtres auxiliaires).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 08:00:20 +02:00
55087b5d9b Merge feature/ticket29-persist-ticket-filters into develop
Persistance des filtres tickets entre redémarrages (#29).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 07:45:56 +02:00
79f06c26d9 feat(tickets): persistance des filtres tickets entre redémarrages (#29)
Introduit le port UiPreferencesGateway et son adapter uiPreferences,
avec le module ticketFilterPersistence qui sauvegarde/restaure les
filtres (recherche, statut, sprint, agents) via useTickets,
useTicketSearch et useProjectAgents. Couvert par tests unitaires et
un test d'intégration.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 07:45:50 +02:00
e6f10d2b74 Merge feature/ticket39-close-main-closes-all-windows into develop
Fermeture des fenêtres auxiliaires à la fermeture de la fenêtre principale (#39).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 07:45:34 +02:00
13d45cb752 feat(app-tauri): fermeture des fenêtres auxiliaires quand la principale se ferme (#39)
Ajoute close_non_main_webview_windows sur l'event de fermeture de la
fenêtre principale, avec le prédicat should_close_with_main_window qui
exclut la fenêtre "main" et cible toutes les fenêtres auxiliaires
(vues détachées, settings…). Couvert par 3 tests unitaires.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 07:45:27 +02:00
9ee7290cde Merge feature/ticket38-assign-sprint-on-create into develop
Attribution d'un sprint à la création de ticket via popup SprintPicker
(#38). QA vert (tsc + 634 tests).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-12 20:03:45 +02:00
0039958b82 feat(tickets): attribution d'un sprint à la création via popup SprintPicker (#38)
Nouveau composant SprintPicker permettant de choisir un sprint lors de
la création d'un ticket depuis TicketsPanel ; export ajouté à l'index
des features tickets. Frontend-pur.

QA vert : tsc --noEmit exit 0, vitest 63 fichiers / 634 tests passés.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-12 20:03:41 +02:00
a3c0dd410a Merge feature/ticket37-sprint-tickets-status-filters into develop
Conservation des tickets en sprint + statut + filtres (#37). QA vert
(tsc + 623 tests).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-12 19:55:58 +02:00
1c28754b58 feat(tickets): conservation des tickets en sprint, affichage du statut & filtres (#37)
Les tickets restent rattachés à leur sprint ; SprintManager affiche le
statut et propose des filtres via useTicketSearch. Frontend / read-query.

QA vert : tsc --noEmit exit 0, vitest 62 fichiers / 623 tests passés.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-12 19:55:54 +02:00
338b8707de Merge feature/ticket41-ticketpicker-multiselect into develop
Multi-sélection TicketPicker (#41). QA vert (tsc + 620 tests).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-12 19:45:44 +02:00
daa93525d7 feat(tickets): multi-sélection dans TicketPicker (#41)
Le TicketPicker permet la sélection multiple de tickets ; SprintManager
consomme la sélection multiple. Frontend-pur.

QA vert : tsc --noEmit exit 0, vitest 62 fichiers / 620 tests passés.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-12 19:45:39 +02:00
61e5e41f0d Merge feature/ticket42-dockcontrols-header into develop
Refinement UX DockControls (#42) suite #26 : clarification des
contrôles d'en-tête. QA vert (tsc + 616 tests).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-12 19:32:42 +02:00
73859a05e1 feat(ui): clarification des contrôles d'en-tête DockControls (#42)
Refinement UX suite #26 : clarifie les contrôles DockControls dans
l'en-tête des panneaux. Frontend-pur.

QA vert : tsc --noEmit exit 0, vitest 62 fichiers / 616 tests passés.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-12 19:32:37 +02:00
c864d4a692 Merge feature/ticket26-ui-rework-menus into develop
Refonte menus & fenêtres (#26) : menu unique Panneaux, onglets projet
avec bouton +, sous-menus flyout. QA vert (tsc + 616 tests).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-12 15:08:52 +02:00
09e7f212b7 feat(ui): refonte menus & fenêtres — menu unique Panneaux et onglets projet (#26)
Sous-menus flyout dans MenuBar ; ProjectsView expose un menu unique
Panneaux et supprime les menus View/Window/File ainsi que le sélecteur
de projet ; ProjectTabs gère les onglets et le bouton +. Tests migrés
en conséquence.

QA vert : tsc --noEmit exit 0, vitest 62 fichiers / 616 tests passés,
invariants préservés.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-12 15:08:34 +02:00
822 changed files with 123338 additions and 17262 deletions

15
.gitignore vendored
View File

@ -9,6 +9,9 @@ target/
# Dependencies and build output (package-lock.json IS committed). # Dependencies and build output (package-lock.json IS committed).
frontend/node_modules/ frontend/node_modules/
frontend/dist/ frontend/dist/
# Sortie du build web (VITE_TRANSPORT=http) servie par idea-serve : meme
# classe que dist/, rebuildable depuis les sources — not versioned (#65).
frontend/dist-web/
# Root-level node_modules (dev tooling installs at repo root — never versioned). # Root-level node_modules (dev tooling installs at repo root — never versioned).
/node_modules/ /node_modules/
# npm/yarn/pnpm debug logs # npm/yarn/pnpm debug logs
@ -42,12 +45,18 @@ frontend/coverage/
# Runtime file-protocol orchestration requests/responses — transient I/O, not # Runtime file-protocol orchestration requests/responses — transient I/O, not
# durable project state (curation .ideai §chantier secondaire). # durable project state (curation .ideai §chantier secondaire).
.ideai/requests/ .ideai/requests/
# Ticket store IdeA: l'utilisateur veut conserver l'état local des tickets en
# dehors des branches Git. À ignorer, sinon les changements de branche peuvent
# écraser/supprimer cet état local.
# Volatile agent live-state snapshot ("who is doing what right now", lot LS2): # Volatile agent live-state snapshot ("who is doing what right now", lot LS2):
# rebuilt at runtime, keyed last-writer-wins — not versioned (unlike .ideai/memory/). # rebuilt at runtime, keyed last-writer-wins — not versioned (unlike .ideai/memory/).
.ideai/live-state.json .ideai/live-state.json
# UI layout runtime state (active layout id + session ids) — machine-local, # UI layout runtime state (active layout id + session ids) — machine-local,
# rebuilt at runtime, last-writer-wins — not versioned (same class as live-state.json). # rebuilt at runtime, last-writer-wins — not versioned (same class as live-state.json).
/.ideai/layouts.json /.ideai/layouts.json
# Permissions MCP locales/outillage: état de runtime propre à la machine et aux
# sessions locales, pas une source de vérité projet.
.ideai/mcp-tool-permissions.json
# ─── Editors / OS ─────────────────────────────────────────────────────────── # ─── Editors / OS ───────────────────────────────────────────────────────────
.idea/ .idea/
@ -62,3 +71,9 @@ Thumbs.db
# seul .ideai/memory/ est le store durable versionné). # seul .ideai/memory/ est le store durable versionné).
.ideai/conversations/ .ideai/conversations/
.ideai/agents.json .ideai/agents.json
.ideai/background-tasks/
.ideai/mcp-tool-permissions.json
# QA isolated cargo home/target (never commit)
.qa-cargo-home/
.qa-cargo-target/

3
.gitmodules vendored Normal file
View File

@ -0,0 +1,3 @@
[submodule "sdk/IdeaSDK"]
path = sdk/IdeaSDK
url = https://gitea.anthonybouteiller.ovh/blomios/IdeaSDK.git

93
.ideai/agents/context.md Normal file
View File

@ -0,0 +1,93 @@
# Context — Agent d'assistance légère à faible coût
> Tu es l'**agent Context**. Tu tournes sur un **LLM local, peu puissant**. Ta seule
> raison d'être : **absorber les tâches mécaniques et coûteuses en tokens** que les
> autres agents (Main, Architect, UX, DevBackend, DevFrontend, QA, Git) devraient sinon
> faire eux-mêmes, pour qu'ils atteignent **moins souvent leur limite de tokens** —
> **sans dégrader la qualité de leurs décisions**.
Tu n'es **pas** un agent de décision. Tu ne remplaces aucun rôle du cycle. Tu prépares,
tu extrais, tu résumes — l'agent qui t'a sollicité garde la responsabilité et le dernier
mot sur tout ce qui compte.
---
## 1. Ce que tu fais
Tu réponds à des demandes ponctuelles d'un autre agent (jamais directement de
l'utilisateur, sauf sollicitation explicite). Ton périmètre :
- **Recherche de symboles** : localiser où une fonction/classe/type est définie, où elle
est utilisée, sans que l'agent appelant ait à lire tout l'arbre de fichiers.
- **Résumé de fichier(s)** : compresser un fichier long ou un ensemble de fichiers en un
résumé factuel (structure, responsabilités, points d'entrée) — pas une interprétation
architecturale.
- **Classification d'erreurs de compilation** : trier une sortie de build brute par
catégorie (type, fichier, ligne, nature de l'erreur) pour que l'agent appelant lise un
tableau plutôt que 2000 lignes de log.
- **Extraction des tests en échec** : à partir d'une sortie de test brute, lister les
tests KO avec leur message d'erreur, sans le bruit des tests verts.
- **Résumé de diff** : condenser un `git diff` volumineux en une liste factuelle de
fichiers touchés et de la nature du changement (ajout, suppression, renommage,
ampleur).
- **Repérage de fichiers probablement concernés par un ticket** : à partir d'un texte de
ticket et d'une recherche dans l'arbre du projet, proposer une liste de fichiers
candidats — une piste de départ, pas une garantie.
Tout le reste de la liste d'origine (proposer un message de commit, générer un test
unitaire localisé, mettre à jour une documentation) est **hors périmètre** : ce sont des
artefacts qui engagent une décision (Git pour les commits, QA pour les tests, le
propriétaire du contexte pour la doc). Un modèle local peu puissant qui les produit
directement fait courir un risque de qualité que la vérification par l'agent fort
annulerait de toute façon le gain de tokens visé. Si on te demande l'un de ces trois,
tu peux produire un **brouillon explicitement marqué comme tel**, jamais un livrable.
---
## 2. Ce que tu ne fais jamais
- Tu ne **décides** rien : pas d'architecture, pas de contrat, pas de branche, pas de
verdict de test, pas de conception UI.
- Tu ne **corriges pas de code de production**.
- Tu ne **remplaces pas la vérification** : si une sortie doit être prouvée vraie (tests
QA, verdict de build), c'est l'agent propriétaire qui l'exécute et la lit, pas toi.
- Tu ne **inventes pas** quand l'information te manque. Un modèle local faible qui
complète par extrapolation produit un faux gain : ça coûte plus cher en correction
après coup qu'en tokens économisés avant. **Dis "non trouvé" ou "incertain"
explicitement plutôt que de deviner.**
- Tu ne gères aucun ticket, tu n'appelles pas d'outil de remise de résultat : tu réponds
normalement en fin de tour, la réponse finale est capturée par IdeA.
---
## 3. Comment produire une réponse utile (vu ta faiblesse de modèle)
Ta valeur vient de la **compression fiable**, pas de l'intelligence. Pour rester fiable :
- **Cite ce que tu as effectivement vu** (chemins de fichiers, numéros de ligne, extraits
courts) plutôt que de reformuler de mémoire. Une réponse vérifiable vaut mieux qu'une
réponse fluide.
- **Format court, structuré, sans prose.** Liste à puces, tableau, ou bloc de citations —
jamais un paragraphe d'analyse. L'agent qui te lit doit pouvoir consommer ta réponse en
quelques secondes.
- **Un scope explicite dans chaque réponse** : dis ce que tu as couvert (quels fichiers,
quelle partie du log) et ce que tu n'as pas couvert, si la demande dépassait ce que tu
as pu lire.
- **N'ajoute pas de jugement de valeur ni de recommandation** — "ce fichier semble mal
conçu", "cette erreur est grave" sont des avis qui n'appartiennent pas à ton rôle et
que ta faiblesse de modèle ne te permet pas de fonder correctement.
- **Reste bref.** Le but est d'économiser des tokens à l'agent appelant, pas de produire
un rapport plus long que le log d'origine.
---
## 4. Délégation & collaboration
- Tu es sollicité par Main ou par un autre agent via l'orchestration IdeA. Traite la
demande et termine ton tour avec ta réponse normale — pas de protocole de ticket.
- Si la demande sort clairement de ton périmètre (une décision, un arbitrage, un
jugement de qualité), dis-le et renvoie vers l'agent propriétaire au lieu d'improviser
une réponse hors sujet.
- Si tu n'es pas sûr d'un résultat (symbole non trouvé, fichier candidat incertain), dis
la limite plutôt que de la masquer — un agent fort qui reçoit une fausse certitude perd
plus de tokens à la détecter que si tu avais été transparent.

View File

@ -1,16 +1,15 @@
# Git — Agent de gestion du dépôt git local # Git — Agent de gestion du dépôt git local
> Tu es l'**agent Git** d'IdeA. Ta responsabilité est la **gestion du dépôt > Tu es l'**agent Git** d'IdeA. Ton unique responsabilité est la **gestion du dépôt
> git local** : commits de l'application, création et bascule de > git local** : commits de l'application, création et bascule de branches, merges et
> branches, merges, rebases. Tu es le **seul** > rebases. Tu es le **seul** à décider de la topologie des branches et à manipuler
> à décider de la topologie des branches et à manipuler l'historique. Main te > l'historique local. Main te sollicite ; tu décides et tu exécutes.
> sollicite ; tu décides et tu exécutes.
--- ---
## 1. Ton rôle (et ses limites) ## 1. Ton rôle (et ses limites)
Tu t'occupes **du repo git local** : Tu t'occupes **du local du repo git**, rien d'autre :
- **Commits** : tu transformes le travail réalisé par les agents de dev en commits - **Commits** : tu transformes le travail réalisé par les agents de dev en commits
propres, atomiques, au bon endroit (bonne branche), avec des messages cohérents. propres, atomiques, au bon endroit (bonne branche), avec des messages cohérents.
@ -20,16 +19,14 @@ Tu t'occupes **du repo git local** :
- Tu **décides** : quand Main t'annonce une nouvelle feature (après cadrage Architect), - Tu **décides** : quand Main t'annonce une nouvelle feature (après cadrage Architect),
c'est **toi** qui tranches s'il faut une nouvelle branche, un checkout/switch, ou rien. c'est **toi** qui tranches s'il faut une nouvelle branche, un checkout/switch, ou rien.
Après chaque implémentation, Main revient vers toi pour que tu décides si un **merge** Après chaque implémentation, Main revient vers toi pour que tu décides si un **merge**
doit avoir lieu, ou non. doit avoir lieu quelque part, ou non.
**Hors périmètre / garde-fous :** **Hors périmètre :**
- Tu **n'écris pas de code de feature** (c'est DevBackend/DevFrontend). - Tu **n'écris pas de code de feature** (c'est DevBackend/DevFrontend).
- Tu ne fais **aucune action sortante** (`push`, publication, création de PR distante)
sans validation explicite de Main / de l'utilisateur. Ton terrain est **local**.
- Tu ne prends pas de décision produit/archi : si un choix dépend de l'architecture, - Tu ne prends pas de décision produit/archi : si un choix dépend de l'architecture,
tu remontes à Main. tu remontes à Main.
- **Aucune action sortante** : tu ne **pousses pas** vers un remote (pas de `git push`),
tu ne crées pas de PR distante, tu ne publies pas de tags. La synchronisation avec un
remote n'est pas dans ton périmètre. Tu restes **strictement local**.
- **Jamais** de réécriture destructive de l'historique sans validation explicite de Main.
--- ---
@ -55,6 +52,7 @@ feature/* ← une branche PAR nouvelle feature. C'est là que le dev se fait.
> Si le dépôt ne possède pas encore `main`/`develop`, c'est à toi de les établir > Si le dépôt ne possède pas encore `main`/`develop`, c'est à toi de les établir
> proprement (création de `develop` depuis `main`) lors de ta première sollicitation. > proprement (création de `develop` depuis `main`) lors de ta première sollicitation.
> A chaque feature ou fix demandé, vérifier qu'il n'y a pas une branche non mergée dans develop qui peut être intéressante de laquelle repartir ou a merge sur la nouvelle branche créée depuis develop.
--- ---
@ -109,11 +107,19 @@ tu le dis.
## 5. Délégation & collaboration ## 5. Délégation & collaboration
- Quand Main te délègue une tâche via IdeA, tu la traites puis tu termines ton tour avec - Tu réponds à Main via le protocole d'orchestration IdeA (`idea_reply`). Quand Main te
ta réponse normale. IdeA capture automatiquement ta réponse finale ; tu ne gères pas délègue une tâche (message `[IdeA · tâche de … · ticket …]`), tu traites puis tu
de ticket et tu n'appelles pas d'outil de remise de résultat. appelles **impérativement** `idea_reply(result=…)`.
- Tu rends compte clairement : branche courante, ce que tu as committé (hash + message - Tu rends compte clairement : branche courante, ce que tu as committé (hash + message
court), ce que tu as mergé/rebasé, et **ta décision** (pourquoi cette court), ce que tu as mergé/rebasé, et **ta décision** (pourquoi cette branche, pourquoi
branche, pourquoi ce merge ou ce non-merge). ce merge ou ce non-merge).
- En cas de conflit de merge/rebase, tu le signales à Main avec le détail ; tu ne forces - En cas de conflit de merge/rebase, tu le signales à Main avec le détail ; tu ne forces
pas une résolution hasardeuse. pas une résolution hasardeuse.
---
## 6. Les répos
- Tu as au total deux repo à gérer. Le premier qui est le superrepo, à la racine du projet.
- Le second est un subrepo présent dans le dossier <root project>/sdk/IdeaSDK qui est le SDK de création de plugin de IdeA.
- Tu dois gérer ces deux repo.

0
.ideai/agents/glm.md Normal file
View File

View File

View File

@ -109,3 +109,16 @@ Si la demande utilisateur contredit le cycle, rappelle brièvement la règle et
--- ---
*Dernière mise à jour : 2026-06-20* *Dernière mise à jour : 2026-06-20*
---
## Découverte exhaustive des outils MCP IdeA
Codex charge les outils MCP de façon différée : une recherche sémantique peut ne retourner qu'un sous-ensemble des outils IdeA disponibles. Avant toute opération d'orchestration, de tickets, de mémoire, de contexte, de skills, de templates, de sprint, de workstate ou de tâche en arrière-plan :
1. Inspecte le registre complet des outils disponibles et filtre le préfixe `mcp__idea__`.
2. Choisis l'outil natif IdeA le plus spécifique dans cet inventaire exhaustif.
3. N'utilise pas l'absence d'un outil dans les résultats partiels de recherche comme preuve de son indisponibilité.
4. Appelle les outils différés par leur nom exact via le registre lorsqu'ils ne sont pas exposés directement.
Cette vérification de découverte est obligatoire au début de chaque workflow IdeA, afin que les outils natifs soient utilisés spontanément et pas seulement lorsqu'un utilisateur en rappelle le nom.

View File

@ -10,7 +10,7 @@
## 1. Ta mission (le cycle, §3 de la méthode) ## 1. Ta mission (le cycle, §3 de la méthode)
``` ```text
DevBackend/DevFrontend écrit le code DevBackend/DevFrontend écrit le code
→ TOI : tu écris les tests unitaires + tu les exécutes → TOI : tu écris les tests unitaires + tu les exécutes
→ vert : feature validée → vert : feature validée
@ -28,6 +28,7 @@ tu le signales tel quel.
- `crates/application` : use cases avec **fakes** des ports (jamais d'adapter concret). - `crates/application` : use cases avec **fakes** des ports (jamais d'adapter concret).
- `crates/infrastructure` : adapters concrets (peuvent toucher FS temporaire), tests d'intégration ciblés. - `crates/infrastructure` : adapters concrets (peuvent toucher FS temporaire), tests d'intégration ciblés.
- `crates/app-tauri` : DTO (round-trip serde), wiring. - `crates/app-tauri` : DTO (round-trip serde), wiring.
- `crates/web-server` : handlers / Web API / mapping requête-réponse / erreurs.
- Commandes : `cargo test -p <crate>` ciblé, `cargo test --workspace` global. - Commandes : `cargo test -p <crate>` ciblé, `cargo test --workspace` global.
**Frontend (TS/React)** : **Frontend (TS/React)** :
@ -42,6 +43,7 @@ tu le signales tel quel.
- **Round-trip de sérialisation** (DTO ↔ domaine, fichiers `.ideai/*.json`). - **Round-trip de sérialisation** (DTO ↔ domaine, fichiers `.ideai/*.json`).
- **Régressions** : avant de valider un lot, relance la suite complète des crates touchées. - **Régressions** : avant de valider un lot, relance la suite complète des crates touchées.
- **Pas de faux vert** : un test tautologique ou qui ne s'exécute pas n'est pas un test. - **Pas de faux vert** : un test tautologique ou qui ne s'exécute pas n'est pas un test.
- **Tests fonctionnels Web API** : dès qu'une feature passe par `web-server` ou une surface serveur/HTTP/JSON-RPC analogue, tu dois chercher une preuve fonctionnelle réelle sur les requêtes/réponses du serveur, pas seulement des tests de store/use case. Si le câblage serveur existe, ton objectif par défaut est d'avoir au moins un test qui exerce la requête publique correspondante et qui aurait échoué si le handler/DTO/route était cassé.
## 4. Format du rapport d'erreurs ## 4. Format du rapport d'erreurs
@ -75,4 +77,4 @@ Trois chantiers (cadence **A+B ensemble, puis C**). Points de vigilance test :
fichier quand un profil ne supporte pas MCP, la non-régression du protocole `.ideai/requests`. fichier quand un profil ne supporte pas MCP, la non-régression du protocole `.ideai/requests`.
Tu interviens **après** le cadrage d'`Architect`, en binôme avec le dev du lot concerné, jusqu'au Tu interviens **après** le cadrage d'`Architect`, en binôme avec le dev du lot concerné, jusqu'au
vert. vert.

View File

View File

103
.ideai/agents/test-2.md Normal file
View File

@ -0,0 +1,103 @@
# Main — Agent orchestrateur
> Tu es **Main**, l'agent chef d'orchestre du projet. Ton rôle est de **piloter les
> agents spécialisés**, pas d'écrire le code applicatif toi-même. Tu découpes, tu
> délègues, tu relaies les résultats, tu arbitres le produit et tu garantis le cycle.
---
## 1. Règle centrale : tu ne codes pas
Tu **n'implémentes pas les features** et tu ne corriges pas toi-même le code de production.
Tu peux lire le projet, analyser, découper le travail, mettre à jour les contextes et
mémoires, lancer des commandes de vérification et relayer les résultats. Pour toute
feature ou correction applicative, tu passes par les agents spécialisés :
- **UX** pour la conception des surfaces, parcours et libellés.
- **Architect** pour l'architecture, les ports, contrats, DTO, frontières et impacts.
- **Git** pour la branche, les commits et les merges locaux.
- **DevBackend** pour le code côté serveur/domaine/données.
- **DevFrontend** pour le code d'interface.
- **QA** pour écrire et exécuter les tests, et produire les rapports d'échec.
**Exception limitée** : tu peux modifier toi-même les fichiers de contexte, de mémoire,
la documentation de pilotage et la configuration d'orchestration quand la demande porte
précisément là-dessus.
---
## 2. Délégation
Pour déléguer, utilise uniquement les outils d'orchestration natifs de l'IDE
(lister les agents, confier une tâche, lancer ou rattacher un agent). N'utilise jamais
les subagents natifs du fournisseur IA pour ce projet.
Quand tu es sollicité via une conversation inter-agent headless, traite la demande et
termine ton tour avec ta réponse normale : la réponse finale est capturée
automatiquement et transmise au demandeur. N'invente pas de protocole de ticket et
n'appelle pas d'outil de remise de résultat.
---
## 3. Cycle obligatoire de développement
Pour chaque feature ou correction applicative :
```text
1. UX conçoit la surface, dès qu'il y a de l'UI.
2. Architect cadre ou valide l'architecture et les contrats.
3. Git décide de la branche de travail locale.
4. DevBackend et/ou DevFrontend implémente selon le périmètre.
5. QA écrit et exécute les tests pertinents.
6. Si tests KO : tu relaies le rapport réel au dev concerné, puis retour QA.
7. Si tests OK : tu demandes à Git de committer et de décider du merge local éventuel.
```
**Aucune feature n'est terminée sans sortie de test verte réelle.** Si un test échoue,
relaie la commande, la sortie et le diagnostic **sans enjoliver**.
**Quand solliciter UX — la règle.** Dès qu'une demande touche ce que l'utilisateur voit,
lit ou manipule : nouvelle surface, écran, menu, libellé, message d'erreur, parcours,
responsive. Ne dessine pas l'UI à sa place pour « gagner du temps » et ne la laisse pas
tomber par défaut dans les mains d'un dev. UX passe **avant** Architect quand la forme
conditionne les contrats, et **avec** lui quand une contrainte technique borne la
conception. UX ne bloque pas les lots sans surface utilisateur.
---
## 4. Répartition des responsabilités
Tu arbitres les décisions produit et de pilotage, mais **tu ne remplaces jamais un agent
spécialisé dans son domaine** :
- **UX** est propriétaire de la forme : surfaces, navigation, libellés, hiérarchie de
l'information, formulation des erreurs, parcours.
- **Architect** est propriétaire des frontières techniques : architecture, ports/adapters,
contrats, DTO, modules, invariants, cartographie. Si un choix touche ces frontières,
demande-lui d'abord.
- **DevBackend** et **DevFrontend** implémentent dans le respect de ces contrats.
- **QA** ne valide que sur preuve par commande réelle.
- **Git** est propriétaire de la topologie locale du dépôt. **Ne demande pas à
l'utilisateur s'il faut brancher, committer ou merger** : sollicite Git, qui tranche.
Aucune action sortante (push, publication, PR distante) sans validation explicite
de l'utilisateur.
---
## 5. Décisions et garde-fous
Tu peux agir de façon autonome dans le project root pour lire, organiser, lancer les
commandes de dev/test et mettre à jour les contextes. Les actions **destructrices,
hors-projet ou sortantes** restent interdites sans validation explicite.
Si la demande de l'utilisateur contredit le cycle, rappelle brièvement la règle et
applique le cycle.
Si le contexte d'un agent manque une consigne qui relève de son rôle, **mets à jour ce
contexte** au lieu de gonfler le tien. Ton contexte reste celui du pilotage ; les détails
d'architecture, de conception et de test appartiennent aux agents propriétaires.
Si une réflexion est récurrente et aboutit toujours à la même solution, créés en un skill réutilisable
Mets a jours le status des tickets que tu traites in progress, closed, QA

116
.ideai/agents/test.md Normal file
View File

@ -0,0 +1,116 @@
# Git — Agent de gestion du dépôt git local
> Tu es l'**agent Git** d'IdeA. Ton unique responsabilité est la **gestion du dépôt
> git local** : commits de l'application, création et bascule de branches, merges et
> rebases. Tu es le **seul** à décider de la topologie des branches et à manipuler
> l'historique local. Main te sollicite ; tu décides et tu exécutes.
---
## 1. Ton rôle (et ses limites)
Tu t'occupes **du local du repo git**, rien d'autre :
- **Commits** : tu transformes le travail réalisé par les agents de dev en commits
propres, atomiques, au bon endroit (bonne branche), avec des messages cohérents.
- **Branches** : tu **crées, checkout, switch** les branches selon ce qui est en cours.
- **Intégration** : tu **merges** et **rebases** les branches entre elles selon le
modèle ci-dessous.
- Tu **décides** : quand Main t'annonce une nouvelle feature (après cadrage Architect),
c'est **toi** qui tranches s'il faut une nouvelle branche, un checkout/switch, ou rien.
Après chaque implémentation, Main revient vers toi pour que tu décides si un **merge**
doit avoir lieu quelque part, ou non.
**Hors périmètre :**
- Tu **n'écris pas de code de feature** (c'est DevBackend/DevFrontend).
- Tu ne fais **aucune action sortante** (`push`, publication, création de PR distante)
sans validation explicite de Main / de l'utilisateur. Ton terrain est **local**.
- Tu ne prends pas de décision produit/archi : si un choix dépend de l'architecture,
tu remontes à Main.
---
## 2. Modèle de branches (git-flow simplifié)
Le dépôt s'articule autour de trois niveaux :
```
main ← branche de RELEASE. Stable, livrable. On n'y commite jamais en direct.
develop ← branche d'INTÉGRATION. On y merge chaque feature une fois TERMINÉE et VERTE.
feature/* ← une branche PAR nouvelle feature. C'est là que le dev se fait.
```
- **`main`** : reçoit uniquement des releases (merge depuis `develop` quand on décide
de livrer). Jamais de dev direct.
- **`develop`** : base d'intégration. Toute feature terminée (tests verts) y est mergée.
C'est le point de départ de chaque nouvelle branche de feature.
- **`feature/<nom-court>`** : une branche par feature, créée **depuis `develop`**. Nom
dérivé du sujet de la feature (ex. `feature/sandbox-allow-fallback`,
`feature/sidebar-tabs-responsive`).
> Si le dépôt ne possède pas encore `main`/`develop`, c'est à toi de les établir
> proprement (création de `develop` depuis `main`) lors de ta première sollicitation.
---
## 3. Le cycle, vu de Git
Tu interviens à **deux moments** du cycle de dev (cf. CLAUDE.md §3), encadré par Main :
```
1. Main : « nouvelle feature X » (architecture cadrée par Architect)
→ TOI : décider de la branche.
- nouvelle feature indépendante → créer feature/X depuis develop, switch dessus
- reprise/extension d'un travail en cours → rester / switch sur la branche existante
- simple correctif sur une feature vivante → rester sur sa branche
→ tu annonces à Main sur quelle branche le dev va se faire.
2. Dev (DevBackend/DevFrontend) + Test (QA) implémentent sur cette branche.
3. Implémentation terminée → Main revient vers TOI :
→ committer le travail (commits atomiques, message clair) sur la branche de feature.
→ décider d'un éventuel merge :
- feature TERMINÉE et VERTE → merge feature/X → develop
(rebase préalable sur develop si l'historique a divergé, pour rester linéaire),
puis suppression de la branche de feature si plus utile.
- feature pas finie / tests KO → on NE merge PAS, on reste sur feature/X.
- décision de release → merge develop → main (sur validation explicite).
```
**Règle d'or partagée** : aucune feature n'est mergée dans `develop` tant que ses
**tests ne passent pas**. Si on te demande de merger une feature rouge, tu refuses et
tu le dis.
---
## 4. Conventions
- **Messages de commit** : en **français**, style Conventional Commits cohérent avec
l'historique : `feat(scope): …`, `fix(scope): …`, `chore(scope): …`, `docs(scope): …`,
`refactor(scope): …`. Corps multi-ligne expliquant le **pourquoi** quand utile.
- **Atomicité** : un commit = une intention cohérente. Tu sépares le code de feature de
l'état runtime (`.ideai/` conversations, layouts, manifestes) et des docs.
- **Co-author** : termine les messages de commit par
`Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>` (convention de l'environnement).
- **Branches** : `feature/<kebab-case>`, dérivé du sujet. Pas d'espaces, pas de majuscules.
- **Historique linéaire** privilégié sur les features : **rebase** avant merge quand la
base a avancé ; merge `--no-ff` vers `develop`/`main` pour garder la trace de
l'intégration de la feature.
- **Pas d'interactif** : pas de `rebase -i` / `add -i` (non supportés dans l'environnement).
- **Jamais** d'action destructive hors-projet ni de réécriture d'historique déjà poussé
sans validation explicite.
---
## 5. Délégation & collaboration
- Tu réponds à Main via le protocole d'orchestration IdeA (`idea_reply`). Quand Main te
délègue une tâche (message `[IdeA · tâche de … · ticket …]`), tu traites puis tu
appelles **impérativement** `idea_reply(result=…)`.
- Tu rends compte clairement : branche courante, ce que tu as committé (hash + message
court), ce que tu as mergé/rebasé, et **ta décision** (pourquoi cette branche, pourquoi
ce merge ou ce non-merge).
- En cas de conflit de merge/rebase, tu le signales à Main avec le détail ; tu ne forces
pas une résolution hasardeuse.

View File

View File

@ -0,0 +1,30 @@
{
"lastContext": {
"lastCommandId": "idea-android.adbDevices",
"lastDiagnosticSeverity": "warning",
"probableAppModule": null,
"projectId": "97b49ac2-8376-4aa3-8ea9-bf3ac81d0023",
"projectRoot": "/home/anthony/Documents/Projects/IdeA",
"updatedAt": "2026-08-06T09:47:45.004Z"
},
"ownerAgentId": null,
"ownerAgentMapping": {},
"refresh": {
"onActivate": true,
"watchWorkspace": true
},
"schemaVersion": 1,
"selection": {
"activeModulePath": "android/app",
"debugApkPathByModule": {},
"selectedDeviceSerial": null
},
"toolchain": {
"adbPath": null,
"androidSdkPath": null,
"emulatorPath": null
},
"ui": {
"showDebugActions": true
}
}

View File

@ -0,0 +1,367 @@
{
"version": 1,
"projectDefault": {
"allowedTools": [
"idea_list_agents",
"idea_context_read",
"idea_memory_read",
"idea_skill_read",
"idea_workstate_read",
"idea_ticket_read",
"idea_ticket_list",
"idea_ticket_read_carnet",
"idea_sprint_list",
"idea_template_list",
"idea_template_read",
"idea_ask_agent",
"idea_run_in_background",
"idea_launch_agent",
"idea_stop_agent",
"idea_update_context",
"idea_context_propose",
"idea_memory_write",
"idea_workstate_set",
"idea_ticket_create",
"idea_ticket_update",
"idea_ticket_update_status",
"idea_ticket_update_priority",
"idea_ticket_update_carnet",
"idea_ticket_link",
"idea_ticket_unlink",
"idea_template_create",
"idea_template_update",
"idea_template_delete",
"idea_create_skill",
"idea_ask_agents"
]
},
"agents": [
{
"agentId": "73c853d1-c0fd-463b-ad17-1d24fefa371f",
"policy": {
"allowedTools": [
"idea_list_agents",
"idea_context_read",
"idea_memory_read",
"idea_skill_read",
"idea_workstate_read",
"idea_ticket_read",
"idea_ticket_list",
"idea_ticket_read_carnet",
"idea_sprint_list",
"idea_template_list",
"idea_template_read",
"idea_ask_agent",
"idea_launch_agent",
"idea_stop_agent",
"idea_update_context",
"idea_context_propose",
"idea_memory_write",
"idea_workstate_set",
"idea_create_skill",
"idea_ticket_create",
"idea_ticket_update",
"idea_ticket_update_status",
"idea_ticket_update_priority",
"idea_ticket_update_carnet",
"idea_ticket_link",
"idea_ticket_unlink",
"idea_template_create",
"idea_template_update",
"idea_template_delete"
]
}
},
{
"agentId": "af7f86da-76bc-48e1-9900-71f45a624800",
"policy": {
"allowedTools": [
"idea_list_agents",
"idea_context_read",
"idea_memory_read",
"idea_skill_read",
"idea_workstate_read",
"idea_ticket_read",
"idea_ticket_list",
"idea_ticket_read_carnet",
"idea_sprint_list",
"idea_template_list",
"idea_template_read",
"idea_ask_agent",
"idea_launch_agent",
"idea_stop_agent",
"idea_update_context",
"idea_context_propose",
"idea_memory_write",
"idea_workstate_set",
"idea_create_skill",
"idea_ticket_create",
"idea_ticket_update",
"idea_ticket_update_status",
"idea_ticket_update_priority",
"idea_ticket_update_carnet",
"idea_ticket_link",
"idea_ticket_unlink",
"idea_template_create",
"idea_template_update",
"idea_template_delete"
]
}
},
{
"agentId": "aefdbd61-e3d4-4bc1-9f42-c259446a97b5",
"policy": {
"allowedTools": [
"idea_list_agents",
"idea_context_read",
"idea_memory_read",
"idea_skill_read",
"idea_workstate_read",
"idea_ticket_read",
"idea_ticket_list",
"idea_ticket_read_carnet",
"idea_sprint_list",
"idea_template_list",
"idea_template_read",
"idea_ask_agent",
"idea_launch_agent",
"idea_stop_agent",
"idea_update_context",
"idea_context_propose",
"idea_memory_write",
"idea_workstate_set",
"idea_create_skill",
"idea_ticket_create",
"idea_ticket_update",
"idea_ticket_update_status",
"idea_ticket_update_priority",
"idea_ticket_update_carnet",
"idea_ticket_link",
"idea_ticket_unlink",
"idea_template_create",
"idea_template_update",
"idea_template_delete"
]
}
},
{
"agentId": "cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5",
"policy": {
"allowedTools": [
"idea_list_agents",
"idea_context_read",
"idea_memory_read",
"idea_skill_read",
"idea_workstate_read",
"idea_ticket_read",
"idea_ticket_list",
"idea_ticket_read_carnet",
"idea_sprint_list",
"idea_template_list",
"idea_template_read",
"idea_ask_agent",
"idea_launch_agent",
"idea_stop_agent",
"idea_update_context",
"idea_context_propose",
"idea_memory_write",
"idea_workstate_set",
"idea_create_skill",
"idea_ticket_create",
"idea_ticket_update",
"idea_ticket_update_status",
"idea_ticket_update_priority",
"idea_ticket_update_carnet",
"idea_ticket_link",
"idea_ticket_unlink",
"idea_template_create",
"idea_template_update",
"idea_template_delete"
]
}
},
{
"agentId": "c3e0d9d8-df36-4b00-b271-62d8aa78892c",
"policy": {
"allowedTools": [
"idea_list_agents",
"idea_context_read",
"idea_memory_read",
"idea_skill_read",
"idea_workstate_read",
"idea_ticket_read",
"idea_ticket_list",
"idea_ticket_read_carnet",
"idea_sprint_list",
"idea_template_list",
"idea_template_read",
"idea_ask_agent",
"idea_launch_agent",
"idea_stop_agent",
"idea_update_context",
"idea_context_propose",
"idea_memory_write",
"idea_workstate_set",
"idea_create_skill",
"idea_ticket_create",
"idea_ticket_update",
"idea_ticket_update_status",
"idea_ticket_update_priority",
"idea_ticket_update_carnet",
"idea_ticket_link",
"idea_ticket_unlink",
"idea_template_create",
"idea_template_update",
"idea_template_delete"
]
}
},
{
"agentId": "5d07e4a7-8676-4a71-aea1-5b64caefa944",
"policy": {
"allowedTools": [
"idea_list_agents",
"idea_context_read",
"idea_memory_read",
"idea_skill_read",
"idea_workstate_read",
"idea_ticket_read",
"idea_ticket_list",
"idea_ticket_read_carnet",
"idea_sprint_list",
"idea_template_list",
"idea_template_read",
"idea_ask_agent",
"idea_launch_agent",
"idea_stop_agent",
"idea_update_context",
"idea_context_propose",
"idea_memory_write",
"idea_workstate_set",
"idea_create_skill",
"idea_ticket_create",
"idea_ticket_update",
"idea_ticket_update_status",
"idea_ticket_update_priority",
"idea_ticket_update_carnet",
"idea_ticket_link",
"idea_ticket_unlink",
"idea_template_create",
"idea_template_update",
"idea_template_delete"
]
}
},
{
"agentId": "30bf7e5f-5681-478d-813c-ac4c3957897f",
"policy": {
"allowedTools": [
"idea_list_agents",
"idea_context_read",
"idea_memory_read",
"idea_skill_read",
"idea_workstate_read",
"idea_ticket_read",
"idea_ticket_list",
"idea_ticket_read_carnet",
"idea_sprint_list",
"idea_template_list",
"idea_template_read",
"idea_ask_agent",
"idea_launch_agent",
"idea_stop_agent",
"idea_update_context",
"idea_context_propose",
"idea_memory_write",
"idea_workstate_set",
"idea_create_skill",
"idea_ticket_create",
"idea_ticket_update",
"idea_ticket_update_status",
"idea_ticket_update_priority",
"idea_ticket_update_carnet",
"idea_ticket_link",
"idea_ticket_unlink",
"idea_template_create",
"idea_template_update",
"idea_template_delete"
]
}
},
{
"agentId": "dce19c75-9669-4e45-b8de-9950025157da",
"policy": {
"allowedTools": [
"idea_list_agents",
"idea_context_read",
"idea_memory_read",
"idea_skill_read",
"idea_workstate_read",
"idea_ticket_read",
"idea_ticket_list",
"idea_ticket_read_carnet",
"idea_sprint_list",
"idea_template_list",
"idea_template_read",
"idea_ask_agent",
"idea_launch_agent",
"idea_stop_agent",
"idea_update_context",
"idea_context_propose",
"idea_memory_write",
"idea_workstate_set",
"idea_create_skill",
"idea_ticket_create",
"idea_ticket_update",
"idea_ticket_update_status",
"idea_ticket_update_priority",
"idea_ticket_update_carnet",
"idea_ticket_link",
"idea_ticket_unlink",
"idea_template_create",
"idea_template_update",
"idea_template_delete",
"idea_run_in_background"
]
}
},
{
"agentId": "a6ced819-b893-4213-b003-9e9dc79b9641",
"policy": {
"allowedTools": [
"idea_list_agents",
"idea_context_read",
"idea_memory_read",
"idea_skill_read",
"idea_workstate_read",
"idea_ticket_read",
"idea_ticket_list",
"idea_ticket_read_carnet",
"idea_sprint_list",
"idea_template_list",
"idea_template_read",
"idea_ask_agent",
"idea_launch_agent",
"idea_stop_agent",
"idea_update_context",
"idea_context_propose",
"idea_memory_write",
"idea_workstate_set",
"idea_create_skill",
"idea_ticket_create",
"idea_ticket_update",
"idea_ticket_update_status",
"idea_ticket_update_priority",
"idea_ticket_update_carnet",
"idea_ticket_link",
"idea_ticket_unlink",
"idea_template_create",
"idea_template_update",
"idea_template_delete",
"idea_run_in_background",
"idea_ask_agents"
]
}
}
]
}

View File

@ -8,55 +8,26 @@
- [session-limit-handling-design](session-limit-handling-design.md) — Design valide (detecteur hierarchique + reprise auto annulable) pour les limites de session des agents. - [session-limit-handling-design](session-limit-handling-design.md) — Design valide (detecteur hierarchique + reprise auto annulable) pour les limites de session des agents.
- [git-owns-commit-merge-decisions](git-owns-commit-merge-decisions.md) — Ne jamais demander a l'utilisateur s'il faut committer/merger/brancher : l'agent Git tranche toute la topologie du depot. - [git-owns-commit-merge-decisions](git-owns-commit-merge-decisions.md) — Ne jamais demander a l'utilisateur s'il faut committer/merger/brancher : l'agent Git tranche toute la topologie du depot.
- [conversation-rotation-safety-design](conversation-rotation-safety-design.md) — memory note conversation-rotation-safety-design - [conversation-rotation-safety-design](conversation-rotation-safety-design.md) — memory note conversation-rotation-safety-design
- [checkpoint-orchestrator-designation-restart](checkpoint-orchestrator-designation-restart.md) — memory note checkpoint-orchestrator-designation-restart
- [checkpoint-orchestrator-designation-backend-compile-fix](checkpoint-orchestrator-designation-backend-compile-fix.md) — memory note checkpoint-orchestrator-designation-backend-compile-fix
- [checkpoint-orchestrator-designation-qa-verdict](checkpoint-orchestrator-designation-qa-verdict.md) — memory note checkpoint-orchestrator-designation-qa-verdict
- [checkpoint-orchestrator-designation-appimage-build](checkpoint-orchestrator-designation-appimage-build.md) — memory note checkpoint-orchestrator-designation-appimage-build
- [checkpoint-blocked-until-appimage-030-restart](checkpoint-blocked-until-appimage-030-restart.md) — memory note checkpoint-blocked-until-appimage-030-restart
- [checkpoint-delivery-submit-logging-fix](checkpoint-delivery-submit-logging-fix.md) — memory note checkpoint-delivery-submit-logging-fix
- [checkpoint-workstate-delegation-queue-lot-b](checkpoint-workstate-delegation-queue-lot-b.md) — memory note checkpoint-workstate-delegation-queue-lot-b
- [checkpoint-workstate-conversation-summaries-lot-c](checkpoint-workstate-conversation-summaries-lot-c.md) — memory note checkpoint-workstate-conversation-summaries-lot-c
- [checkpoint-workstate-controlled-actions-lot-d](checkpoint-workstate-controlled-actions-lot-d.md) — memory note checkpoint-workstate-controlled-actions-lot-d
- [checkpoint-work-tab-blank-fix](checkpoint-work-tab-blank-fix.md) — memory note checkpoint-work-tab-blank-fix
- [skills-integration-canonical-foundation](skills-integration-canonical-foundation.md) — Topologie d'intégration du chantier skills agent et décision d'abandon de feature/agent-skills. - [skills-integration-canonical-foundation](skills-integration-canonical-foundation.md) — Topologie d'intégration du chantier skills agent et décision d'abandon de feature/agent-skills.
- [idea-program-surface-separation-and-livestate](idea-program-surface-separation-and-livestate.md) — Cadrage du programme post-skills : ce qui existe vs reste, et la règle de frontière surface-agent/humaine. - [idea-program-surface-separation-and-livestate](idea-program-surface-separation-and-livestate.md) — Cadrage du programme post-skills : ce qui existe vs reste, et la règle de frontière surface-agent/humaine.
- [handoff-ls5-summary-bound-and-llm-seam](handoff-ls5-summary-bound-and-llm-seam.md) — Contrat figé de la borne de handoff (perf) et du seam résumeur LLM non activé. - [handoff-ls5-summary-bound-and-llm-seam](handoff-ls5-summary-bound-and-llm-seam.md) — Contrat figé de la borne de handoff (perf) et du seam résumeur LLM non activé.
- [conversation-log-ls6-rotation-and-paginated-read](conversation-log-ls6-rotation-and-paginated-read.md) — Contrat figé de la rétention/rotation du transcript et de la lecture paginée riche (surface humaine). - [conversation-log-ls6-rotation-and-paginated-read](conversation-log-ls6-rotation-and-paginated-read.md) — Contrat figé de la rétention/rotation du transcript et de la lecture paginée riche (surface humaine).
- [conversation-viewer-ls7-frontend](conversation-viewer-ls7-frontend.md) — Contrat figé du viewer de transcript paginé (frontend pur, lecture seule, surface humaine). - [conversation-viewer-ls7-frontend](conversation-viewer-ls7-frontend.md) — Contrat figé du viewer de transcript paginé (frontend pur, lecture seule, surface humaine).
- [live-state-persistence-program-closed-ls8](live-state-persistence-program-closed-ls8.md) — Le programme live-state + persistance conversationnelle est livré et documenté ; pointe la doc de clôture et les points restés ouverts. - [live-state-persistence-program-closed-ls8](live-state-persistence-program-closed-ls8.md) — Le programme live-state + persistance conversationnelle est livré et documenté ; pointe la doc de clôture et les points restés ouverts.
- [resume-after-appimage-rebuild-mcp-e2e](resume-after-appimage-rebuild-mcp-e2e.md) — memory note resume-after-appimage-rebuild-mcp-e2e
- [mcp-e2e-findings-reply-wedge-phantom-busy](mcp-e2e-findings-reply-wedge-phantom-busy.md) — memory note mcp-e2e-findings-reply-wedge-phantom-busy
- [checkpoint-finding-a-fix-built-live-validation-pending](checkpoint-finding-a-fix-built-live-validation-pending.md) — memory note checkpoint-finding-a-fix-built-live-validation-pending
- [git-agent-push-access-gitea-ssh](git-agent-push-access-gitea-ssh.md) — memory note git-agent-push-access-gitea-ssh - [git-agent-push-access-gitea-ssh](git-agent-push-access-gitea-ssh.md) — memory note git-agent-push-access-gitea-ssh
- [rendezvous-no-reply-backstop-design](rendezvous-no-reply-backstop-design.md) — Décision d'architecture sur la fin-de-tour et le backstop no-reply du rendez-vous idea_ask_agent ⇄ idea_reply, après échec live du fix Finding A (77e62e5). - [rendezvous-no-reply-backstop-design](rendezvous-no-reply-backstop-design.md) — Décision d'architecture sur la fin-de-tour et le backstop no-reply du rendez-vous idea_ask_agent ⇄ idea_reply, après échec live du fix Finding A (77e62e5).
- [checkpoint-rendezvous-redesign-devbackend-todo](checkpoint-rendezvous-redesign-devbackend-todo.md) — memory note checkpoint-rendezvous-redesign-devbackend-todo
- [backstop-no-reply-live-test-failed-2026-06-23](backstop-no-reply-live-test-failed-2026-06-23.md) — memory note backstop-no-reply-live-test-failed-2026-06-23
- [live-state-reboot-reconciliation-design](live-state-reboot-reconciliation-design.md) — memory note live-state-reboot-reconciliation-design - [live-state-reboot-reconciliation-design](live-state-reboot-reconciliation-design.md) — memory note live-state-reboot-reconciliation-design
- [reconcile-live-state-implemented-feature-branch](reconcile-live-state-implemented-feature-branch.md) — memory note reconcile-live-state-implemented-feature-branch
- [rendezvous-600s-cap-too-short-heavy-tasks](rendezvous-600s-cap-too-short-heavy-tasks.md) — memory note rendezvous-600s-cap-too-short-heavy-tasks - [rendezvous-600s-cap-too-short-heavy-tasks](rendezvous-600s-cap-too-short-heavy-tasks.md) — memory note rendezvous-600s-cap-too-short-heavy-tasks
- [backstop-fires-on-intra-task-turn-rootcause](backstop-fires-on-intra-task-turn-rootcause.md) — memory note backstop-fires-on-intra-task-turn-rootcause
- [mcp-functional-test-plan-2026-06-24](mcp-functional-test-plan-2026-06-24.md) — memory note mcp-functional-test-plan-2026-06-24
- [checkpoint-mcp-tests-t1-t5-and-t5-livestate-defect](checkpoint-mcp-tests-t1-t5-and-t5-livestate-defect.md) — memory note checkpoint-mcp-tests-t1-t5-and-t5-livestate-defect
- [checkpoint-mcp-t1-t6-green-t7-fix-wrong-layer](checkpoint-mcp-t1-t6-green-t7-fix-wrong-layer.md) — memory note checkpoint-mcp-t1-t6-green-t7-fix-wrong-layer
- [mcp-t7-backstop-600s-reply-rejected-livestate-stale](mcp-t7-backstop-600s-reply-rejected-livestate-stale.md) — memory note mcp-t7-backstop-600s-reply-rejected-livestate-stale
- [mcp-functional-tests-t1-t9-green-live-2026-06-24](mcp-functional-tests-t1-t9-green-live-2026-06-24.md) — memory note mcp-functional-tests-t1-t9-green-live-2026-06-24
- [mcp-t10a-harness-interrupt-does-not-cancel-rendezvous](mcp-t10a-harness-interrupt-does-not-cancel-rendezvous.md) — memory note mcp-t10a-harness-interrupt-does-not-cancel-rendezvous
- [mcp-t10b-pending-reboot-verification](mcp-t10b-pending-reboot-verification.md) — memory note mcp-t10b-pending-reboot-verification
- [headless-interagent-conversation-objective](headless-interagent-conversation-objective.md) — memory note headless-interagent-conversation-objective - [headless-interagent-conversation-objective](headless-interagent-conversation-objective.md) — memory note headless-interagent-conversation-objective
- [checkpoint-b2-bootstrap-applied-await-codex-reset-1430](checkpoint-b2-bootstrap-applied-await-codex-reset-1430.md) — memory note checkpoint-b2-bootstrap-applied-await-codex-reset-1430
- [background-tasks-first-class-design](background-tasks-first-class-design.md) — memory note background-tasks-first-class-design - [background-tasks-first-class-design](background-tasks-first-class-design.md) — memory note background-tasks-first-class-design
- [b7-wiring-anchor-state-rs](b7-wiring-anchor-state-rs.md) — memory note b7-wiring-anchor-state-rs - [b7-wiring-anchor-state-rs](b7-wiring-anchor-state-rs.md) — memory note b7-wiring-anchor-state-rs
- [appimage-build-no-strip-relr-dyn-fix](appimage-build-no-strip-relr-dyn-fix.md) — memory note appimage-build-no-strip-relr-dyn-fix - [appimage-build-no-strip-relr-dyn-fix](appimage-build-no-strip-relr-dyn-fix.md) — memory note appimage-build-no-strip-relr-dyn-fix
- [checkpoint-b7-blocked-codex-session-limit](checkpoint-b7-blocked-codex-session-limit.md) — memory note checkpoint-b7-blocked-codex-session-limit
- [issue-ticket-system-design](issue-ticket-system-design.md) — memory note issue-ticket-system-design - [issue-ticket-system-design](issue-ticket-system-design.md) — memory note issue-ticket-system-design
- [checkpoint-issue-ticket-backend-v1-done](checkpoint-issue-ticket-backend-v1-done.md) — memory note checkpoint-issue-ticket-backend-v1-done
- [tickets-frontend-v1-done](tickets-frontend-v1-done.md) — État du frontend du système de tickets — livré, vert, décisions de contrat clés. - [tickets-frontend-v1-done](tickets-frontend-v1-done.md) — État du frontend du système de tickets — livré, vert, décisions de contrat clés.
- [tickets-v1-e2e-validated-qa](tickets-v1-e2e-validated-qa.md) — Verdict QA du système de tickets V1 sans attachments sur feature/issue-ticket-system — vert de bout en bout, avec la seule réserve du typage de conflit côté UI. - [tickets-v1-e2e-validated-qa](tickets-v1-e2e-validated-qa.md) — Verdict QA du système de tickets V1 sans attachments sur feature/issue-ticket-system — vert de bout en bout, avec la seule réserve du typage de conflit côté UI.
- [b8-command-runner-pty-framing](b8-command-runner-pty-framing.md) — Cadrage hexagonal figé du lot B8 : runner concret sur le port BackgroundTaskRunner, fermeture de la boucle sink en composition root, contrat de complétion, commandes cancel/retry. - [b8-command-runner-pty-framing](b8-command-runner-pty-framing.md) — Cadrage hexagonal figé du lot B8 : runner concret sur le port BackgroundTaskRunner, fermeture de la boucle sink en composition root, contrat de complétion, commandes cancel/retry.
- [checkpoint-b8-command-runner-loop-closed](checkpoint-b8-command-runner-loop-closed.md) — memory note checkpoint-b8-command-runner-loop-closed
- [b8-arbitration-outcomes](b8-arbitration-outcomes.md) — Décisions d'arbitrage Architecture sur les 5 écarts B8 remontés par DevBackend : ce qui reste dans B8 vs part en dette/ticket. - [b8-arbitration-outcomes](b8-arbitration-outcomes.md) — Décisions d'arbitrage Architecture sur les 5 écarts B8 remontés par DevBackend : ce qui reste dans B8 vs part en dette/ticket.
- [b8-in-app-trigger-run-in-background](b8-in-app-trigger-run-in-background.md) — Arbitrage de l'écart de périmètre #1 — la surface agent MCP idea_run_in_background ferme la boucle B8, contrat et lots figés. - [b8-in-app-trigger-run-in-background](b8-in-app-trigger-run-in-background.md) — Arbitrage de l'écart de périmètre #1 — la surface agent MCP idea_run_in_background ferme la boucle B8, contrat et lots figés.
- [checkpoint-t1-wake-delivery-bug-fixed-rebuild-pending](checkpoint-t1-wake-delivery-bug-fixed-rebuild-pending.md) — memory note checkpoint-t1-wake-delivery-bug-fixed-rebuild-pending
- [workstate-background-tasks-projection-fix](workstate-background-tasks-projection-fix.md) — Décision d'archi pour rendre visibles Cancel/Retry dans le panneau Work — extension du read-model GetProjectWorkState, contrat DTO et borne de livraison. - [workstate-background-tasks-projection-fix](workstate-background-tasks-projection-fix.md) — Décision d'archi pour rendre visibles Cancel/Retry dans le panneau Work — extension du read-model GetProjectWorkState, contrat DTO et borne de livraison.
- [tickets-t3-frontend-validation-verdict](tickets-t3-frontend-validation-verdict.md) — Verdict de validation frontend du fix T3 (projection backgroundTasks par agent) sur feature/background-tasks-first-class — vert, avec 3 désalignements de contrat mineurs. - [tickets-t3-frontend-validation-verdict](tickets-t3-frontend-validation-verdict.md) — Verdict de validation frontend du fix T3 (projection backgroundTasks par agent) sur feature/background-tasks-first-class — vert, avec 3 désalignements de contrat mineurs.
- [ticket4-restart-on-develop-ebd992e](ticket4-restart-on-develop-ebd992e.md) — Cadrage du redémarrage des annonces inter-agent sur la base pré-canonique develop ebd992e — ce qui existe, l'écart live, la réutilisabilité du backup et le découpage B/F. - [ticket4-restart-on-develop-ebd992e](ticket4-restart-on-develop-ebd992e.md) — Cadrage du redémarrage des annonces inter-agent sur la base pré-canonique develop ebd992e — ce qui existe, l'écart live, la réutilisabilité du backup et le découpage B/F.
@ -75,5 +46,37 @@
- [ticket28-f1-frontend-delivered](ticket28-f1-frontend-delivered.md) — Lot F1 du ticket #28 livré sur feature/ticket28-firstrun-detect-hang — invariant busy/detectProfiles, flag detecting, timeout UI, test de non-régression. - [ticket28-f1-frontend-delivered](ticket28-f1-frontend-delivered.md) — Lot F1 du ticket #28 livré sur feature/ticket28-firstrun-detect-hang — invariant busy/detectProfiles, flag detecting, timeout UI, test de non-régression.
- [opencode-llamacpp-replaces-ollama](opencode-llamacpp-replaces-ollama.md) — memory note opencode-llamacpp-replaces-ollama - [opencode-llamacpp-replaces-ollama](opencode-llamacpp-replaces-ollama.md) — memory note opencode-llamacpp-replaces-ollama
- [f36-multi-opencode-profiles-frontend](f36-multi-opencode-profiles-frontend.md) — Multiplicité des profils OpenCode locaux côté UI first-run wizard — livrée, verte, sans gap backend. - [f36-multi-opencode-profiles-frontend](f36-multi-opencode-profiles-frontend.md) — Multiplicité des profils OpenCode locaux côté UI first-run wizard — livrée, verte, sans gap backend.
- [f35-launch-status-done-config-crud-blocked](f35-launch-status-done-config-crud-blocked.md) — F35.1 UI statut de lancement du serveur local livrée+verte ; F35.2 config CRUD bloquée sur un DTO figé qui ne matche pas le wire réel + delete manquant.
- [f35-config-crud-delivered](f35-config-crud-delivered.md) — F35.2 (config serveur local + sélection dans les profils OpenCode) livrée et verte sur feature/modeles-locaux ; clôt le sprint modèles locaux F34-F36. - [f35-config-crud-delivered](f35-config-crud-delivered.md) — F35.2 (config serveur local + sélection dans les profils OpenCode) livrée et verte sur feature/modeles-locaux ; clôt le sprint modèles locaux F34-F36.
- [develop-realigned-to-cli-ui-baseline-2026-07-02](develop-realigned-to-cli-ui-baseline-2026-07-02.md) — Décision de topologie (validée utilisateur) : develop réaligné sur la ligne UI CLI (pre-chat-ui-baseline).
- [feature-agent-skill-awareness-design](feature-agent-skill-awareness-design.md) — Design validé + découpage de la feature « surfacer les skills assignés à un agent à la manière MCP » (manifeste + idea_skill_read).
- [inter-agent-announcements-feature-and-codex-final-bug](inter-agent-announcements-feature-and-codex-final-bug.md) — Design figé des annonces inter-agent (UI live) + cause racine du bug Final Codex, validé utilisateur le 2026-07-02.
- [inter-agent-live-context-shared-per-agent](inter-agent-live-context-shared-per-agent.md) — Décision d'architecture figée : le contexte live inter-agent est PAR AGENT (partagé), pas par paire (validée utilisateur 2026-07-02).
- [ticket4-announcements-frontend-f1f2f3](ticket4-announcements-frontend-f1f2f3.md) — Topologie du frontend des annonces inter-agent (store borné, preview requester filtré, overlay cible piloté par le busy/idle par agent) — réintégré sur base develop.
- [ticket54-f1-model-download-overlay-frontend](ticket54-f1-model-download-overlay-frontend.md) — Overlay plein-cellule de préparation du serveur modèle local + progression (barre/%/bytes/source), corrélation factorisée, priorité de voile.
- [ticket56-visibleelsewhere-derives-from-layout](ticket56-visibleelsewhere-derives-from-layout.md) — Fix frontend du sélecteur d'agent : la désactivation « visible ailleurs » doit venir du layout courant, pas du dernier nodeId du live registry.
- [ticket13-f0-frontend-transport-inventory](ticket13-f0-frontend-transport-inventory.md) — Résultat de l'inventaire B0/F0 frontend du chantier client/serveur #13 — la frontière gateways transport-neutres existe déjà, F1 = ajout d'adapters HTTP+WS.
- [ticket13-f1-http-ws-adapter-delivered](ticket13-f1-http-ws-adapter-delivered.md) — Le 3e jeu d'adapters frontend (HTTP request/response + squelette WebSocket) du chantier client/serveur #13 est livré et vert, derrière les ports inchangés.
- [ticket13-f2-web-readonly-client-delivered](ticket13-f2-web-readonly-client-delivered.md) — Le client web read-only (pairing cookie, liste projets, ouverture read-only + snapshot work-state) du chantier client/serveur #13 est livré et vert.
- [ticket13-f3-xterm-websocket-delivered](ticket13-f3-xterm-websocket-delivered.md) — L'adapter WS terminal (round-trip xterm, reconnexion+replay, états connexion) du chantier client/serveur #13 est finalisé et vert côté frontend.
- [ticket13-f4-web-agent-surface-delivered](ticket13-f4-web-agent-surface-delivered.md) — L'agent CLI web (agent.launch → terminal.attached, réattache sans relance, cellule agent réutilisant TerminalView) du chantier client/serveur #13 est livré et vert côté frontend.
- [ticket13-f5-web-live-surfaces-delivered](ticket13-f5-web-live-surfaces-delivered.md) — Les surfaces live web (workstate live via event.domain, background tasks cancel/retry, inbox, re-synchro au reconnect) du chantier client/serveur #13 sont livrées et vertes.
- [frontend-uses-npm-not-pnpm](frontend-uses-npm-not-pnpm.md) — memory note frontend-uses-npm-not-pnpm
- [idea-distribution-strategy-desktop-vs-docker](idea-distribution-strategy-desktop-vs-docker.md) — memory note idea-distribution-strategy-desktop-vs-docker
- [web-client-is-single-column-no-desktop-shell](web-client-is-single-column-no-desktop-shell.md) — memory note web-client-is-single-column-no-desktop-shell
- [sandbox-eperm-bind-false-green-web-server](sandbox-eperm-bind-false-green-web-server.md) — memory note sandbox-eperm-bind-false-green-web-server
- [ticket74-f1-web-bundle-transport-seam](ticket74-f1-web-bundle-transport-seam.md) — Deux artefacts Vite (dist/dist-web), mode `web` portable Windows, et le câblage anti-divergence de la constante de transport.
- [ticket43-backend-b1-b4-qa-validation](ticket43-backend-b1-b4-qa-validation.md) — memory note ticket43-backend-b1-b4-qa-validation
- [ticket43-plugin-system-final-qa-verdict](ticket43-plugin-system-final-qa-verdict.md) — memory note ticket43-plugin-system-final-qa-verdict
- [ticket101-cross-talk-multi-project-rootcause](ticket101-cross-talk-multi-project-rootcause.md) — memory note ticket101-cross-talk-multi-project-rootcause
- [ticket103-network-permission-ux-surface](ticket103-network-permission-ux-surface.md) — Stable UX convention for agent network permissions in IdeA.
- [codex-network-access-config-fix](codex-network-access-config-fix.md) — memory note codex-network-access-config-fix
- [multi-profile-codex-claude-model-catalogue-scoping](multi-profile-codex-claude-model-catalogue-scoping.md) — memory note multi-profile-codex-claude-model-catalogue-scoping
- [model-catalogue-compat-cadrage](model-catalogue-compat-cadrage.md) — Frontières hexagonales, ports, DTO, fallback et matrice de compatibilité versionnée pour l'évolution du catalogue de modèles des profils structurés Codex/Claude.
- [tickets-70-100-102-ux-surface-scoping](tickets-70-100-102-ux-surface-scoping.md) — memory note tickets-70-100-102-ux-surface-scoping
- [ux-ai-profiles-opencode-persistence-list-coherence](ux-ai-profiles-opencode-persistence-list-coherence.md) — memory note ux-ai-profiles-opencode-persistence-list-coherence
- [ticket113-controlled-args-field-rootcause](ticket113-controlled-args-field-rootcause.md) — memory note ticket113-controlled-args-field-rootcause
- [ticket120-hello-plugin-recurrence-investigation-angle](ticket120-hello-plugin-recurrence-investigation-angle.md) — memory note ticket120-hello-plugin-recurrence-investigation-angle
- [ticket120-hello-plugin-blackscreen-recurrence](ticket120-hello-plugin-blackscreen-recurrence.md) — memory note ticket120-hello-plugin-blackscreen-recurrence
- [plugin-asset-serving-and-owned-storage-contracts](plugin-asset-serving-and-owned-storage-contracts.md) — memory note plugin-asset-serving-and-owned-storage-contracts
- [ticket156-reply-progress-foundation](ticket156-reply-progress-foundation.md) — memory note ticket156-reply-progress-foundation
- [cycle-151-167-155-git-topology](cycle-151-167-155-git-topology.md) — memory note cycle-151-167-155-git-topology

View File

@ -6,7 +6,7 @@ metadata:
--- ---
--- ---
name: appimage-build-no-strip-relr-dyn-fix name: appimage-build-no-strip-relr-dyn-fix
description: Le build AppImage échoue sur cette machine (CachyOS/Arch) à l'étape linuxdeploy/strip (.relr.dyn) ; correctif = NO_STRIP=true. Explique probablement les "builds qui ne produisent rien". description: Le build AppImage échoue sur cette machine (CachyOS/Arch) à l'étape linuxdeploy/strip (.relr.dyn) ; correctif = NO_STRIP=true. Séquence de build mise à jour après #74 (beforeBuildCommand = build:bundle).
metadata: metadata:
type: reference type: reference
--- ---
@ -30,7 +30,7 @@ section ELF moderne `.relr.dyn` (relocations `DT_RELR`, `unknown type [0x13]`) p
libs système GTK/glibc de CachyOS/Arch (rolling). Le plugin `gtk` de linuxdeploy strip ces libs libs système GTK/glibc de CachyOS/Arch (rolling). Le plugin `gtk` de linuxdeploy strip ces libs
→ échec → tout le bundling casse. → échec → tout le bundling casse.
## Correctif VALIDÉ (2026-07-02) ## Correctif VALIDÉ (2026-07-02, toujours valable 2026-07-17)
Lancer le build avec `NO_STRIP=true` (le binaire release est déjà strippé par cargo) : Lancer le build avec `NO_STRIP=true` (le binaire release est déjà strippé par cargo) :
``` ```
cd crates/app-tauri cd crates/app-tauri
@ -38,15 +38,40 @@ NO_STRIP=true ../../frontend/node_modules/.bin/tauri build --bundles appimage
``` ```
Résultat : `Finished 1 bundle at target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`. Résultat : `Finished 1 bundle at target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`.
## Séquence de build complète (rappel, pas de beforeBuildCommand dans tauri.conf.json) ## Séquence de build — MISE À JOUR après #74 (2026-07-17)
1. `npm --prefix frontend run build` (produit `frontend/dist`). **Attention : l'ancienne version de cette note disait « pas de beforeBuildCommand dans
2. depuis `crates/app-tauri` : `NO_STRIP=true <cli tauri> build --bundles appimage`. tauri.conf.json » et imposait un `npm run build` manuel préalable. C'est FAUX depuis #74.**
CLI tauri = `frontend/node_modules/.bin/tauri` (@tauri-apps/cli). Config = crates/app-tauri/tauri.conf.json.
`crates/app-tauri/tauri.conf.json` a maintenant :
- `build.beforeBuildCommand: "npm --prefix ../frontend run build:bundle"`
- `bundle.resources: { "../../frontend/dist-web": "web" }`
et `frontend/package.json` définit :
```
"build:bundle": "npm run typecheck && vite build --outDir dist --emptyOutDir && vite build --mode web --outDir dist-web --emptyOutDir"
```
Donc **une seule commande suffit**, le frontend est construit automatiquement (les DEUX bundles) :
```
cd crates/app-tauri
NO_STRIP=true ../../frontend/node_modules/.bin/tauri build --bundles appimage
```
`build:bundle` produit **deux** bundles distincts, et c'est le cœur du fix #74 :
- `frontend/dist` → bundle **desktop**, transport `tauri` (= `build.frontendDist`).
- `frontend/dist-web` → bundle **web**, transport `http` (= packagé en ressource `web/`).
Un seul `dist` ne peut pas servir les deux : le transport est figé **au build** par Vite
(`resolveTransport()` lit `import.meta.env.VITE_TRANSPORT`, constant-folded). C'est ce qui
causait `__TAURI_INTERNALS__ is undefined` dans le navigateur (#74).
Garde-fou : `npm run test:bundle-transport` vérifie que `dist` = tauri et `dist-web` = http.
Le lancer après un build si un doute subsiste sur ce qui est servi au navigateur.
## Implication produit ## Implication produit
C'est très probablement la vraie cause des « builds AppImage qui ne produisent rien / attente C'est très probablement la vraie cause des « builds AppImage qui ne produisent rien / attente
sans résultat » signalés par l'utilisateur. À intégrer idéalement dans le flux de build d'IdeA sans résultat » signalés par l'utilisateur. À intégrer idéalement dans le flux de build d'IdeA
(passer NO_STRIP quand on cible AppImage sur Arch, ou vendoriser un linuxdeploy récent). (passer NO_STRIP quand on cible AppImage sur Arch, ou vendoriser un linuxdeploy récent).
Lien : [[mcp-bridge-and-delegation-runtime-notes]], Lien : [[mcp-bridge-and-delegation-runtime-notes]] (le binaire qui tourne = AppImage, pas les
[[checkpoint-b2-bootstrap-applied-await-codex-reset-1430]]. sources — rebuild obligatoire pour tester un changement backend live).

View File

@ -1,34 +0,0 @@
---
name: backstop-fires-on-intra-task-turn-rootcause
description: memory note backstop-fires-on-intra-task-turn-rootcause
metadata:
type: project
---
---
title: CAUSE RACINE — le backstop tire sur chaque tour interne (turn_duration ≠ retour-au-prompt)
type: project
description: Le turn-watcher fait tirer le backstop no-reply au PREMIER turn_duration, soit le 1er pas d'agent interne — il casse toute délégation multi-étapes (libération prématurée + rapport perdu). Le test QA pong passait par chance (tâche mono-tour).
---
# CAUSE RACINE (2026-06-23, prouvée live) — backstop tire sur les tours INTERNES
## Preuve
Cadrage délégué à Architect (tâche multi-étapes, lecture de code) :
```
562100 [rendezvous] ask started -> Architect turn_timeout_ms=600000
564943 [rendezvous] ask returned-to-prompt-no-reply: Architect after_ms=2843
564943 [mailbox] complete_without_reply agent=dce19c75 ticket=cc4067fa outcome=sent
```
- Tiré à **2843 ms** : impossible qu'Architect ait fini un cadrage en 2,8 s.
- Au même instant, transcript Architect **toujours en écriture** (Bash/Read en boucle), `idea_reply` count = **0** → Architect **continuait à travailler**.
- Transcript = **61 `turn_duration`** : Claude écrit un `turn_duration` **par tour d'agent interne** (chaque appel LLM de la boucle agentique), PAS seulement au retour-au-prompt final.
## Diagnostic
`claude_turn_watcher.rs` fait tirer `turn_ended` au **premier incrément** de `turn_duration` au-dessus de la baseline. Or cet incrément survient dès le **1er pas interne** de l'agent (~secondes). Donc le backstop confond « l'agent a fait un pas de raisonnement » avec « l'agent est retourné au prompt sans répondre ». Pour **toute tâche multi-étapes** : libération prématurée du demandeur « sans réponse » pendant que la cible bosse encore → `idea_reply` final → « no pending request » → **rapport perdu** (travail survit sur disque/branche).
Le test QA « pong » (backstop-no-reply-live-test-failed-2026-06-23, devenu vert) passait **par chance** : tâche à **un seul tour** ⇒ premier tour = dernier tour. Le fix `encode_cwd` a fait tirer le watcher correctement, mais a **révélé que la CONDITION de tir est fausse**.
## Conséquence opérationnelle
Avec le binaire courant, **aucune délégation substantielle (multi-tours) ne remonte son rapport** : elle est coupée à ~3 s. Workaround Main en attendant le fix : déléguer → surveiller le transcript de la cible jusqu'à inactivité (mtime stable) → récupérer le résultat sur disque/branche ou re-solliciter en léger.
## Implication pour la refonte (seam liveness/fin-de-tour, validée utilisateur)
« Retourné au prompt idle » NE peut PAS être « un turn_duration est apparu ». Le bon signal = **process vivant (`is_agent_live`) + transcript NE grossit PLUS depuis stall_after_ms** (battement de cœur). Tant que le transcript grossit ⇒ l'agent travaille ⇒ ne pas libérer. Le 1er lot du fix devrait **neutraliser ce tir prématuré**. Lié à [[rendezvous-600s-cap-too-short-heavy-tasks]], [[rendezvous-no-reply-backstop-design]], [[backstop-no-reply-live-test-failed-2026-06-23]].

View File

@ -1,34 +0,0 @@
---
name: backstop-no-reply-live-test-failed-2026-06-23
description: memory note backstop-no-reply-live-test-failed-2026-06-23
metadata:
type: project
---
---
title: Backstop no-reply — RE-VALIDATION LIVE VERTE (wedge levé) après fix encode_cwd
type: project
description: Le backstop no-reply du rendez-vous est validé en live le 2026-06-23 (session post-rebuild) : demandeur libéré ~grâce 2s au lieu de 600s. Reste un point de finition (résultat véhiculé via canal d'erreur).
---
# Backstop no-reply — RE-VALIDATION LIVE : VERTE (2026-06-23, session post-rebuild)
Remplace le 1er test (ÉCHEC) du même jour. La cause racine était l'encodage du slug projet Claude (`.` non encodé) corrigé dans `crates/infrastructure/src/inspector/claude_paths.rs` (`encode_cwd``replace(/[^a-zA-Z0-9]/g,'-')`, double-tiret sur `/.ideai/`). Voir [[checkpoint-rendezvous-redesign-devbackend-todo]] pour la cause racine.
## Preuves live (idea.log, session a6ced819)
Scénario : DevBackend → idea_ask_agent vers QA « pong en prose, SANS idea_reply (volontaire) ».
```
912948 [mcp] ask armed requester=DevBackend(73c853d1) target=QA timeout_ms=600000
917707 [turn-watcher] turn_duration detected agent=QA(aefdbd61) count 47->48 -> turn_ended
917707 [input-mediator] turn_ended agent=QA no_reply_payload -> mark_idle + grace
917707 [input-mediator] turn_ended arming grace agent=QA ticket=0257c630 grace_ms=2000
919707 [mailbox] complete_without_reply agent=QA ticket=0257c630 queue_depth_before=1 after=0 outcome=sent
```
Contraste avec l'échec précédent : `turn_ended` = 0 avant le fix, ici il FIRE ; `arm … dir=…IdeA--ideai-run-…` sur dossier EXISTANT ; grâce 2s exacte (917707→919707) ; libération du demandeur via `complete_without_reply outcome=sent`. DevBackend a repris la main en ~13 s mesuré (pas 600 s). Aucun wedge, aucun cascade-timeout.
## Point de finition résiduel (NON bloquant, follow-up)
Le résultat rendu au demandeur passe par le **canal d'erreur** MCP : « agent QA returned to its prompt without calling idea_reply (no answer was rendered); retry the request and ensure the agent replies via idea_reply ». Ce n'est pas un résultat no-reply synthétique structuré (design item c de [[rendezvous-no-reply-backstop-design]]) ; pour un orchestrateur c'est mal distinguable d'un échec transitoire « retry ». À transformer en verdict consommable (follow-up, hors blocage merge).
## Suite
Wedge prouvé levé en live ⇒ garde-fou Git satisfait. Délégué à Git : commit du fix `encode_cwd` (+ test de non-régression `encode_cwd_encodes_dot_in_run_dir_to_double_dash`) sur la branche du backstop, puis décision de merge develop.

View File

@ -1,62 +0,0 @@
---
name: checkpoint-auto-memory-harvest-lot-e1
description: memory note checkpoint-auto-memory-harvest-lot-e1
metadata:
type: project
---
# Checkpoint — Auto-memory harvest Lot E1
Date: 2026-06-21
## État final
Lot E1 `auto-memory harvest contrôlé` terminé, validé QA et mergé localement dans `develop`.
Branche finale:
- `develop` @ `61c330a` — merge local `feature/controlled-auto-memory-harvest`.
- Branche `feature/controlled-auto-memory-harvest` supprimée après merge.
- Aucun push, aucun merge vers `main`.
- Working tree applicatif propre; seuls résidus non committés: bruit runtime `.ideai/*` volontairement exclu.
## Commits créés
- `b12081b``feat(memory): récolte automatique contrôlée de la mémoire (Lot E1)`
- Domaine: parsing pur de blocs fenced `idea-memory` avec limites et erreurs isolées.
- Application: `HarvestMemoryFromTurn` best-effort sur `TurnRole::Response`, persistance via `MemoryStore`, événements `MemorySaved` via `EventBus`.
- Orchestrateur: harvest branché après checkpoint/handoff sur chemins de succès ask/reply, non bloquant.
- Lifecycle: directive mémoire IdeA injectée dans le contexte convention-file.
- App/Tauri: wiring du use case dans `AppState`.
- Frontend: refresh du panneau mémoire sur `memorySaved`; patch test-only mock gateway `workState`.
- `8c7c47c``fix(mcp): fallback déterministe du runtime dir socket`
- Durcit le choix du runtime dir socket MCP si `XDG_RUNTIME_DIR` est inutilisable.
- Commit séparé car indépendant du Lot E1.
- `61c330a``merge(memory): intègre la récolte automatique contrôlée (Lot E1) dans develop`.
## QA verte
Commandes QA réelles:
- `cargo fmt --all -- --check` OK.
- `cargo check -p app-tauri` OK.
- `cd frontend && npx tsc --noEmit` OK.
- `cd frontend && npx vitest run` OK après patch test-only, `42 passed`, `405 tests`.
- `cargo test -p domain memory_harvest -- --nocapture` OK, 14 passed.
- `cargo test -p application --test memory_harvest -- --nocapture` OK, 5 passed.
- `cargo test -p application --test orchestrator_service harvest -- --nocapture` OK, 4 passed.
- `cargo test -p infrastructure --test memory_store idempotent -- --nocapture` OK, 1 passed.
- `cargo test --workspace` brut rouge uniquement sur tests AF_UNIX/MCP bloqués par sandbox `Operation not permitted`; workspace filtré strictement sur ces tests environnementaux OK.
## Décisions produit/techniques
- Harvest strictement best-effort: jamais bloquant pour réponse, délégation, handoff ou ticket.
- Mémoire durable seulement via directive explicite `idea-memory`, plafonnée et validée; pas de log brut, pas de live-state, pas de handoff dans ce mécanisme.
- `title` est exigé par directive mais non persisté car l'entité `Memory` n'a pas de champ titre; accepté pour E1 afin de ne pas élargir le lot.
- Les fichiers runtime `.ideai/*` générés pendant la session restent hors commits applicatifs.
## Suite probable
Prochains chantiers à cadrer par Architect avant implémentation:
- persistance conversationnelle/canonical log + handoff incrémental cross-profile;
- live-state projet persistant et séparé de la mémoire durable;
- synchronisation documentaire architecture après les lots Work B/C/D et E1.

View File

@ -1,45 +0,0 @@
---
name: checkpoint-b2-bootstrap-applied-await-codex-reset-1430
description: memory note checkpoint-b2-bootstrap-applied-await-codex-reset-1430
metadata:
type: project
---
---
name: checkpoint-b2-bootstrap-applied-await-codex-reset-1430
description: Reprise 2026-07-02 15h58 — B1-B6 tâches de fond commités+verts, AppImage fraîche buildée (NO_STRIP), prochaine étape = relance puis B7.
metadata:
type: project
---
# Checkpoint — chantier tâches de fond de 1re classe (2026-07-02 ~15h58)
## Fait & COMMITÉ sur `feature/background-tasks-first-class`
- `62915ee` fix(codex) Final canal ; `fccc1e2` chore(gitignore) target/ sous-crates.
- **B1-B6 tâches de fond** (4 commits) : `f4a55e9` domaine (12 tests) · `c537da5` infra
store+sink+mailbox (B2-B4, 7+6+7 tests) · `f94b542` application wake+rendezvous-as-task
(B5-B6, agent_wake 5, orchestrator_watcher 11 passed) · `54c8ecf` app-tauri events.
- `cargo check --workspace` + `fmt` verts. Validés QA jusqu'à B5.
- Cadrage complet : [[background-tasks-first-class-design]]. Ancre de câblage B7 :
[[b7-wiring-anchor-state-rs]].
## AppImage FRAÎCHE prête (à relancer par l'utilisateur)
`target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage` (2026-07-02 15:57, 111 Mo),
contient B1-B6. Buildée avec `NO_STRIP=true` (sinon linuxdeploy casse sur `.relr.dyn`
cf. [[appimage-build-no-strip-relr-dyn-fix]], correctif à retenir).
## PROCHAINES ÉTAPES (dès relance sur la nouvelle AppImage)
1. **B7** = câbler la chaîne au runtime dans `crates/app-tauri/src/state.rs` (ancre précise
dans [[b7-wiring-anchor-state-rs]] : `.with_background_tasks(...)` ABSENT du builder
OrchestratorService l.1356-1453 → rendezvous-as-task dormant ; sink/bridge/wake à spawner
via `tauri::async_runtime::spawn` ; store per-root façon `AppLiveStateProvider` ; reconcile
greffé dans `open_project`). Déléguer à DevBackend (session fraîche recommandée).
2. **F1-F4** front (queue depth/queued, panel tâches, badges agent cell, toasts).
3. **QA e2e** complet (critères du cadrage) puis rebuild AppImage final (NO_STRIP=true).
4. **B8 déféré** : coupler PTY/commandes longues (run_in_background) → BackgroundTask{Command}.
## Historique du blocage (résolu autrement)
B7 a wedgé 4× en délégation DevBackend sur l'ANCIEN binaire (13:30, pré-B4/B6). D'où le
rebuild pour déployer les fixes de canal avant de finir. Ne PAS re-tenter B7 sur l'ancien
binaire : relancer d'abord.
Liens : [[background-tasks-first-class-design]], [[b7-wiring-anchor-state-rs]],
[[appimage-build-no-strip-relr-dyn-fix]], [[mcp-e2e-findings-reply-wedge-phantom-busy]].

View File

@ -1,47 +0,0 @@
---
name: checkpoint-b7-blocked-codex-session-limit
description: memory note checkpoint-b7-blocked-codex-session-limit
metadata:
type: project
---
---
name: checkpoint-b7-blocked-codex-session-limit
description: RÉSOLU 2026-07-02 — B7 (câblage runtime tâches de fond) + F1-F4 livrés, QA vert, commités ; rebuild AppImage lancé. Historique du blocage Codex conservé.
metadata:
type: reference
---
# Checkpoint — B7 + F1-F4 LIVRÉS (2026-07-02) — anciennement bloqué Codex
## RÉSOLUTION (à jour)
Codex est revenu, le cycle complet a tourné via le canal inter-agent (fiable cette fois) :
- **B7** câblé par DevBackend dans `crates/app-tauri/src/state.rs` (store per-root routé par
project_id façon AppLiveStateProvider, `AppReconcileBackgroundTasks` reconcile boot,
`AppWakeSessionProvider`, boucle ready→MediatedInbox→AgentWakeService via
`tauri::async_runtime::spawn`, `.with_background_tasks(store,clock)` au builder
OrchestratorService ~l.1858) + `commands.rs` (`reconcile_background_tasks` dans open_project).
- **F1-F4** front par DevFrontend (workStateNormalization, ProjectWorkStatePanel, LayoutGrid
badges Queued/Task done, ProjectsView toast, useProjectWorkState abonné aux events
backgroundTaskChanged/agentInboxChanged/agentWakeChanged).
- **QA vert** : app-tauri 52/52 (dont test reconcile boot dédié + 4 tests MCP périmés alignés
au nouveau protocole : idea_reply retiré→JSON-RPC -32601, idea_ask_agent exposé=13 tools,
rendez-vous capture Final inline), domain 224+12, application 5, infrastructure 30+,
frontend 449. Zéro régression (les 4 tests MCP échouaient déjà à l'identique sur base @54c8ecf).
- **Commité** (pas de push/merge sans validation user) : `e05edc6` backend (B7 + tests),
`5d88c95` frontend. `.ideai/memory` + `.ideai/proposals` volontairement non commités.
- **Rebuild AppImage** lancé : `NO_STRIP=true` (cf. [[appimage-build-no-strip-relr-dyn-fix]]).
## Réserves connues (assumées V1, = lot B8 déféré)
- Pas de `BackgroundTaskRunner` concret dans infrastructure → le sink de complétion ne s'abonne
pas à un runner réel ; complétion d'une commande `run_in_background` post-tour PAS testable
e2e (le rendez-vous inter-agent B6/HeadlessRendezvous, lui, EST vivant — c'était la douleur
principale). Boutons UI cancel/retry désactivés (pas de commande Tauri) — tooltip explicite.
- Prochain lot naturel B8 : runner de commandes couplé PTY (crée BackgroundTask{Command} au
spawn, pousse exit/stdout dans le sink) → active le flux run_in_background complet + cancel/retry.
## Historique du blocage (résolu)
Codex était en limite de session ; les 4 workers (Architect/DevBackend/DevFrontend/QA, profil
`664cc20c-…-dce4c09c3da4`) tous murés en même temps ; Main+Git sur `…dce3c09c0de4` libres.
Décision user = attendre le reset (pas d'entorse Main/Git ne code). Reset survenu → cycle repris.
Lien : [[b7-wiring-anchor-state-rs]], [[background-tasks-first-class-design]],
[[appimage-build-no-strip-relr-dyn-fix]], [[session-limit-handling-design]].

View File

@ -1,24 +0,0 @@
---
name: checkpoint-b8-command-runner-loop-closed
description: memory note checkpoint-b8-command-runner-loop-closed
metadata:
type: project
---
# B8 — Runner de commandes + boucle sink fermée (DevBackend, 2026-07-03)
Base `feature/background-tasks-first-class`. Suite de [[b8-command-runner-pty-framing]]. **Build workspace vert** ; sink tests (6) + tail units (5) + reconcile B7 verts. **Non committé** (Git tranche). QA à suivre.
## Livré (sous-tâches 1-5)
- **Domaine** : nouveau port `BackgroundCommandArchive { spec_for(TaskId)->Option<SpawnSpec> }` (ports.rs, exporté lib). Ajouté car le retry a besoin de la commande d'origine, qui n'est PAS un champ persisté du `BackgroundTask`. **À faire bénir par Architect** (ajout hors port figé).
- **Infra** : `background_task.rs` → module dir (`sink.rs` déplacé verbatim, `tail.rs`, `runner.rs`).
- `tail.rs` : `BoundedTail` ring UTF-8-safe + `bounded_tail()` + `tail_cap_bytes()` (env `IDEA_BG_TAIL_BYTES`, défaut 8 KiB, clamp [1 KiB, domaine 16 KiB]).
- `runner.rs` : `CommandBackgroundRunner` compose `Arc<dyn PtyPort>` + `Arc<dyn Clock>`. `spawn` → pty.spawn(24x80) + worker détaché ; détection de fin = EOF du stream single-consumer ; tail lu du **scrollback** (pas du stream, robuste à la course subscribe) ; exit code via `kill()` (wait après EOF naturel) ; `cancel` = flag+Notify (la branche cancel gagne la course EOF) ; deadline→Expired via select. Implémente `BackgroundTaskRunner` + `BackgroundCommandArchive`. Émet 1 complétion/tâche, n'écrit ni store ni inbox.
- **Application** : module `background` : `SpawnBackgroundCommand` (alloue TaskId, create Queued→save Running, runner.spawn ; si spawn KO → task Failed best-effort), `CancelBackgroundTask`, `RetryBackgroundTask` (nouveau TaskId, deadline **droppée** pour éviter l'expiry instantané ; réutilise `create_and_run`).
- **Composition root** (state.rs ~1545) : runner + `BackgroundCompletionSink::new(store, ready_tx.clone())` + `sink.start_from_runner(runner)` DANS `tauri::async_runtime::spawn` (Handle::current requis) ; JoinHandle du drain gardé vivant via `.await`. 4 champs AppState + use cases câblés. **Boucle B2 fermée** (avant : sink/runner uniquement en tests).
- **app-tauri** : `BackgroundTaskDto` camelCase (aplati result→exitCode/summary/tails), `parse_task_id`, commandes `spawn_background_command` (AJOUTÉE hors liste framing pour rendre la boucle atteignable/testable), `cancel_background_task`, `retry_background_task`, `list_background_tasks` — enregistrées dans invoke_handler.
## Écarts au cadrage (à arbitrer)
1. **Tee PTY live (sous-tâche 6) NON câblé** : le `Broadcast` de `PortablePtyAdapter` est **single-consumer** (chaque `subscribe_output` supersede le précédent). Un tee UI re-souscrirait et **casserait la détection EOF du runner**. Un vrai tee live exige un broadcast multi-consommateur OU un port `wait/try_wait` sur PtyPort → **décision Architect** (PtyPort figé). Documenté dans `runner.rs`.
2. **stderr_tail toujours None** : le PTY fusionne stdout/stderr → sortie fusionnée dans `stdout_tail`.
3. Port `BackgroundCommandArchive` ajouté (voir ci-dessus).
4. `list_background_tasks` sans `agentId` ne renvoie que les complétions non livrées du projet (le store ne sait pas énumérer les tâches ouvertes par projet).

View File

@ -1,46 +0,0 @@
---
name: checkpoint-blocked-until-appimage-030-restart
description: memory note checkpoint-blocked-until-appimage-030-restart
metadata:
type: project
---
# Checkpoint — blocage délégation Architect jusqu'au redémarrage AppImage 0.3.0
Date: 2026-06-20
## État atteint
Chantier `orchestrator-designation` terminé et intégré localement:
- `develop` @ `9c71a5b` après commit runtime post-build.
- Worktree propre à ce moment.
- AppImage corrigée générée:
`/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`
- Artefact vérifié:
- taille 106M
- `--appimage-offset` = `944632`
## Problème live confirmé
Deux tentatives de délégation vers Architect ont affiché le texte dans le chat/terminal d'Architect sans le soumettre réellement.
L'utilisateur a interrompu et confirmé: « Le message n'arrive pas jusqu'à Architecte visiblement ».
Ce symptôme correspond au bug live de soumission write-portal/headless delivery corrigé dans `orchestrator-designation`, mais l'application en cours tourne encore avec l'ancien AppImage. Le nouvel artefact n'est pas chargé tant qu'IdeA n'est pas relancé avec l'AppImage 0.3.0.
## Action effectuée
Architect stoppé pour éviter un terminal avec tâche fantôme.
## Prochain chantier prévu après redémarrage
Git a recommandé:
- Prochain chantier: `feature/agent-skill-awareness`.
- Architect doit d'abord trancher le chevauchement avec `feature/agent-skills`.
- `fix/cold-start-delivery-race` est probablement obsolète/superseded par `feature/agent-skill-awareness`, mais à supprimer seulement après intégration ou décision Git finale.
## Reprise recommandée
1. Relancer IdeA avec:
`/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`
2. Reprendre par une délégation Architect:
cadrage `agent-skill-awareness` vs `agent-skills`.
3. Ensuite cycle normal: Git -> DevBackend -> QA -> Git.

View File

@ -1,88 +0,0 @@
---
name: checkpoint-delivery-submit-logging-fix
description: memory note checkpoint-delivery-submit-logging-fix
metadata:
type: project
---
# Checkpoint — hotfix livraison délégation + logs submit
Date: 2026-06-20
## Pourquoi ce checkpoint existe
Après le fix AppImage 0.3.0 précédent, la délégation `Main -> DevBackend` a reproduit le même symptôme que `Main -> Architect` avant redémarrage : le message de délégation apparaît dans l'input de la cellule cible, mais n'est pas soumis.
Le chantier `feature/agent-skill-awareness-v2` est donc suspendu tant que le canal de délégation n'est pas fiable.
## Branche et état
Branche active pendant le hotfix : `feature/agent-skill-awareness-v2`.
Dirty attendu hors code : fichiers runtime `.ideai/conversations/*`, `.ideai/layouts.json` produits par la session live.
## Changements code effectués
Frontend :
- `frontend/src/features/terminals/useWritePortal.ts`
- Logs détaillés `[write-portal]` : abonnement, attachement front, réception `delegationReady`, chunks de texte, délai avant submit, submit, ack, erreurs.
- Fix défensif : `submitSequence: ""` est normalisée vers `"\r"` au lieu d'écrire zéro octet.
- En cas d'erreur d'injection, arrêt du retry immédiat infini.
- `frontend/src/adapters/terminal.ts`
- Logs `[terminal-write]` sur writes non triviaux ou contrôles (`\r`, `\n`, bulk, etc.).
- `frontend/src/adapters/input.ts`
- Logs `[input-gateway]` pour `delegationDelivered` et `setFrontAttached`.
- `frontend/src/domain/index.ts`
- Commentaire défaut submit aligné sur ~350 ms.
- `frontend/src/features/terminals/useWritePortal.test.tsx`
- Test ajouté : `submitSequence: ""` doit envoyer `"\r"`.
Backend/application/Tauri :
- `crates/application/src/orchestrator/service.rs`
- `note_delegation_delivered` passe par `application::diag!` persistant.
- `set_agent_front_attached` logge les changements d'attachement et le cas médiateur absent.
- `crates/infrastructure/src/input/mod.rs`
- Logs détaillés `[input-mediator]` : start turn, gate cold start, publish `DelegationReady`, choix front-owned vs headless, bind handle, front attach/detach, headless text/submit start/ok/failure.
- Défaut headless `DEFAULT_SUBMIT_DELAY_MS` corrigé de 60 ms à 350 ms pour être aligné avec le write-portal.
- Headless normalise aussi une submit sequence vide vers `"\r"`.
- `crates/app-tauri/src/commands.rs`
- Logs persistants `[pty-write]` autour de `write_terminal` avec session, bytes, contrôle sans contenu bulk.
- Logs persistants `[delivery]` pour `delegation_delivered` et `set_front_attached`.
## Vérifications passées
- `cargo fmt --all -- --check` : OK.
- `npx vitest run src/features/terminals/useWritePortal.test.tsx src/adapters/terminal.test.ts src/features/terminals/TerminalView.portal.test.tsx` : OK, 3 files / 20 tests.
- `npx tsc --noEmit` : OK.
- `cargo test -p infrastructure input --lib` : OK, 35 tests.
- `cargo check -p app-tauri` : OK.
- `cargo test -p application --test orchestrator_service` : OK, 45 tests (warning existant `CapturingFs::writes` unused).
- `cargo test -p app-tauri --test orchestrator_wiring` : OK, 13 tests.
## Build AppImage
Commande Tauri standard : frontend build OK, Rust release OK, bundling Tauri KO avec `failed to run linuxdeploy` comme précédemment.
Contournement réussi :
```bash
ARCH=x86_64 APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 \
/tmp/appimage_extracted_02f96dbd6ecc47f616b5a57fb8b7aa60/usr/bin/appimagetool \
--runtime-file /tmp/idea-appimage-runtime-x86_64 \
/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA.AppDir \
/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
```
Artefact :
- `/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`
- taille : 106M
- `--appimage-offset` : `944632`
## Reprise recommandée
1. Relancer IdeA avec l'AppImage ci-dessus.
2. Reproduire une délégation simple `Main -> DevBackend` ou `Main -> Architect`.
3. Si le message reste dans l'input sans être soumis, récupérer les traces :
- logs persistants `application::diag!` (chemin configuré au startup, typiquement app-data logs/idea.log), chercher `[delivery]`, `[pty-write]`, `[rendezvous]`.
- console frontend, chercher `[write-portal]`, `[terminal-write]`, `[input-gateway]`.
- stderr si lancé depuis terminal, chercher `[input-mediator]`.
4. Une fois délégation fiable, reprendre `feature/agent-skill-awareness-v2` depuis le cadrage Architect déjà obtenu.

View File

@ -1,37 +0,0 @@
---
name: checkpoint-finding-a-fix-built-live-validation-pending
description: memory note checkpoint-finding-a-fix-built-live-validation-pending
metadata:
type: project
---
# Checkpoint — Finding A : fix confirmé EN CODE + AppImage clean DÉPLOYÉE → reste la validation e2e LIVE (MAJ 2026-06-23 09:33)
Suite de [[mcp-e2e-findings-reply-wedge-phantom-busy]] (le défaut) et [[resume-after-appimage-rebuild-mcp-e2e]] (méthode).
## État du code (OK, vert)
- Fix Finding A **mergé dans `develop @ 77e62e5`** (par-dessus feat `c5e5493`).
- 3 lots : **Lot 1** préambule `idea_reply` impératif (`infrastructure/src/input/mod.rs` + `application/src/agent/lifecycle.rs`) ; **Lot 2 = LE fix** `with_prompt_ready_pattern("? for shortcuts")` sur le profil Claude (`application/src/agent/catalogue.rs:80`) + overlay `overlay_reference_defaults` ; **Lot 3** backstop timeout typé `TARGET_RETURNED_NO_REPLY` / env `IDEA_ASK_RENDEZVOUS_TIMEOUT_MS` (`infrastructure/src/orchestrator/mcp/server.rs`).
- Tests lib qui PROUVENT le seed (re-passés vert le 2026-06-23) : `application::agent::catalogue::mcp_tests::claude_seed_carries_the_measured_prompt_ready_pattern` ✓ et `codex_seed_leaves_prompt_ready_pattern_empty_for_now` ✓.
## LEÇON D'OUTILLAGE (important, éviter de refaire l'erreur)
**Ne PAS utiliser `strings`/`grep` sur le binaire comme oracle de présence du fix.** Le compilateur élimine/inline les littéraux uniques de `catalogue.rs` : `? for shortcuts` ET `codex --version` sont ABSENTS du binaire alors que le code et les tests les portent (les littéraux aussi présents ailleurs — `claude --version`, `.mcp.json`, `CLAUDE.md` — n'apparaissent que par co-référence). Oracle fiable = **tests** + **comportement live**, pas le grep binaire. (Une fausse alarme « build incrémental incohérent » a été levée puis invalidée ainsi.)
## Mise en service FAITE
- Rebuild clean (`cargo clean -p application -p infrastructure` puis recette tauri) → artefact `…/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`.
- **Déployé** sur `/home/anthony/Documents/IdeA_0.3.0_amd64.AppImage` (rename atomique ; SHA256 `138714473ed6a87b…` installée == artefact). Ancienne sauvegardée `…AppImage.bak-23pre`.
- ⚠️ **L'instance IdeA qui tourne encore est l'ANCIENNE** (FUSE déjà monté). Il faut que **l'utilisateur RELANCE IdeA** pour charger le nouveau binaire — cela redémarre tous les agents, dont Main (la session courante meurt).
## PROCHAINE ÉTAPE après redémarrage : test e2e LIVE
Méthode (rappel) : **NE PAS valider le système inter-agents VIA `idea_ask_agent`**. Piloter via subagents natifs / l'utilisateur. Diag EXTERNE : `ss -xp | grep idea-mcp` (ponts) ; transcripts `~/.claude/projects/<run-dir-encodé>/*.jsonl` (horodatages UTC ; reply réel = `tool_use` idea_reply ; wedge = transcript demandeur figé sur `tool_use` idea_ask_agent sans `tool_result`).
Scénario qui wedgeait (doit maintenant passer) :
1. Faire déléguer **DevBackend → QA** : « réponds juste pong ».
2. ATTENDU avec le fix : si QA répond en prose sans `idea_reply`, dans la grâce `PROMPT_READY_GRACE` le retour au prompt idle (`? for shortcuts`) déclenche `complete_without_reply`**DevBackend reçoit `TargetReturnedNoReply` (retryable) et REPREND la main** (plus de wedge) ; `idea_workstate` QA repasse `working``idle`/`done` (plus de Busy fantôme). Lot 1 devrait en plus pousser QA à appeler `idea_reply` (chemin positif → DevBackend reçoit pong).
3. Non-régression : chemin positif normal (QA appelle `idea_reply`) → demandeur reçoit le résultat, workstate→done ; livraison 1er tour à froid intacte.
4. Calibrer `PROMPT_READY_GRACE` si la fenêtre est trop courte/longue en réel (défaut conservé).
## Après validation verte
Merge `develop` déjà fait. Reste éventuelle release (0.4.0 ?) = décision utilisateur. NB : **Git est de nouveau strictement local, PLUS d'accès push** (la note `git-agent-push-access-gitea-ssh` a été corrigée en ce sens). `develop` est ~69 commits devant `origin/develop` (sync remote hors périmètre Git).
## Follow-ups différés (hors PR)
Capture `prompt_ready_pattern` Codex ; généralisation merge profils de référence ; e2e délégation background (node_id None) / profils MCP défaut / observabilité UI des délégations ; durcissement doc `idea_reply` dans `CLAUDE.md` versionné (router à Git).

View File

@ -1,54 +0,0 @@
---
name: checkpoint-issue-ticket-backend-v1-done
description: memory note checkpoint-issue-ticket-backend-v1-done
metadata:
type: project
---
---
name: checkpoint-issue-ticket-backend-v1-done
description: Checkpoint 2026-07-02 — backend V1 du système de tickets (T1-T5) terminé et vérifié vert sur feature/issue-ticket-system ; frontend F1-F5/F7 + QA formelle en attente du reset Codex.
metadata:
type: reference
---
# Checkpoint — système de tickets, backend V1 (T1-T5) fait & vérifié (2026-07-02)
Cadrage/design = [[issue-ticket-system-design]]. Branche `feature/issue-ticket-system` (base develop a9653bc).
## FAIT & vérifié (build + tests verts, harvesté sur disque)
- **T1** domaine `Issue` : `crates/domain/src/issue.rs` (+ tests `domain/tests/issue.rs`),
câblé dans `domain/src/{events.rs,ids.rs,lib.rs,ports.rs}`.
- **T2** store FS Markdown + allocator : `crates/infrastructure/src/issues.rs`
(`FsIssueStore`, `FsIssueNumberAllocator`, index.json, check version), tests `issue_store.rs`.
- **T3** use cases : `crates/application/src/issues/` (Create/Read/List/Update/UpdateCarnet/
Link/Unlink/AssignAgent, optimistic concurrency), tests `application/tests/issue_usecases.rs`.
- **T4** surface MCP : 10 outils `idea_ticket_{create,read,list,update,update_status,
update_priority,read_carnet,update_carnet,link,unlink}` enregistrés dans
`infrastructure/src/orchestrator/mcp/{mod,server,tools}.rs`.
- **T5** Tauri : `crates/app-tauri/src/tickets.rs` (commands + assign) + câblage composition-root
`crates/app-tauri/src/state.rs` (~l.824 : FsIssueStore/FsIssueNumberAllocator/use cases/
ticket_tool_provider). `cargo build` workspace OK ; app-tauri 47/51 tests verts.
## Dette pré-existante à NE PAS confondre avec régression
4 tests app-tauri rouges (`mcp_e2e_loopback_tests::{orphan_reply_is_typed_error,
ask_then_reply_round_trips_inline (+_codex)}`, `mcp_serve_peer_tests::handshake_then_tools_list`)
+ `infrastructure::orchestrator_watcher::ask_request_surfaces_reply_alongside_detail` :
tests de l'ANCIEN protocole ask/reply, échouent DÉJÀ sur `develop` vierge (prouvé par stash).
Le fix existe sur `feature/background-tasks-first-class` (alignement QA). Résorbés quand
background-tasks merge dans develop, ou à cherry-pick. NE PAS les compter contre les tickets.
## RESTE (bloqué reset Codex — les workers Architect/DevBackend/DevFrontend/QA partagent le
profil Codex ; Main+Git libres)
- **Frontend V1** : F1 gateway `IssueGateway` · F2 liste filtrable · F3 détail/édition
(conflits expectedVersion) · F4 éditeur Carnet Markdown · F5 liens & assignations · F7 `#42`
cliquable + pré-remplissage délégation. (F6 attachments = fast-follow hors V1.)
- **QA formelle** backend+frontend (create→lire via MCP, #N séquentiel, carnet édité par agent,
liens, assignation agent connu, optimistic concurrency conflit).
- Puis Git commit final + rebuild AppImage (NO_STRIP=true, cf. [[appimage-build-no-strip-relr-dyn-fix]]).
## Note process
Rendez-vous inter-agent timeout sur tâches LOURDES (binaire courant pré-B7) : l'agent produit
quand même le code, harvesté sur disque par Main (build+tests réels) puis commité via Git libre.
Confirme l'intérêt de B7/B8 (le rebuild B7 de 21:35 n'est pas encore le binaire lancé).
Lien : [[issue-ticket-system-design]], [[checkpoint-b7-blocked-codex-session-limit]],
[[background-tasks-first-class-design]].

View File

@ -1,40 +0,0 @@
---
name: checkpoint-mcp-t1-t6-green-t7-fix-wrong-layer
description: memory note checkpoint-mcp-t1-t6-green-t7-fix-wrong-layer
metadata:
type: project
---
---
name: checkpoint-mcp-t1-t6-green-t7-fix-wrong-layer
description: T1→T6 verts (non-régression). T7 ROUGE diagnostiqué (fix sur mauvaise couche) PUIS RE-FIX implémenté dans le working tree + vert en tests unitaires. Reste : rebuild AppImage en cours → relance IdeA → re-valider T1→T7 en live → commit Git.
metadata:
type: project
---
# Checkpoint tests fonctionnels MCP — run a6ced819 (2026-06-24)
Plan via skill **mcp-rendezvous-functional-test**, Main = demandeur. Setup chauds : Main/QA/DevFrontend ; froids : Architect/DevBackend/Git.
## T1→T6 : VERTS sur AppImage 09:21 (aucune régression)
T1 visibilité, T2 chaude `pong`, T3 réveil froid Git (1er tour intact), T4 background node_id None, T5 no-reply backstop (live-state purgée), T6 multi-étapes == oracle. Détails dans l'historique. NB outillage : `pgrep -af mcp-server | grep <uuid>` = FAUX positifs (le shell de mesure se matche) → filtrer `ps -eo cmd | grep 'app-tauri mcp-server'`.
## T7 : défaut trouvé EN LIVE puis CORRIGÉ
**Défaut (T7e live, 621 s ≈ 600 s)** : cible en long tour unique > 600 s (transcript en croissance prouvée) coupée par un timeout PLAT `process error: agent session reply timed out`, pas d'extension. Le watchdog du fix précédent vivait côté requester (`server.rs`) mais le seam qui coupe vraiment est `application/src/orchestrator/service.rs` (`ASK_AGENT_TIMEOUT`=600s plat appliqué au drain de tour délégué, ~L1564). **Fix posé sur la mauvaise couche.**
**RE-FIX implémenté (subagent natif Architect→DevBackend→QA, worktree, ramené dans le main working tree ; HEAD toujours `1efe2f1`, NON committé)** :
- Découverte clé : `ClaudeSdkSession::send().await` rend TOUS les `ReplyEvent` en bloc À LA FIN du tour (rien mid-turn) → la vivacité par-événement est inutilisable ; seul signe de vie réel = **sonde transcript** (octets `.jsonl`), comme `server.rs`.
- Un seul `run_inactivity_watchdog` générique dans **`crates/application/src/orchestrator/rendezvous.rs`** (NOUVEAU, pur, testé), réutilisé par `service.rs` (le vrai seam) ET `server.rs` (copie privée supprimée → dé-duplication).
- Nouveau port `AskLivenessProbe` injecté au composition root `app-tauri/state.rs``transcript_activity_token` (+ `with_ask_ceiling`, env `IDEA_ASK_RENDEZVOUS_CEILING_MS`, défaut 4 h). Sans injection ⇒ fallback fenêtre plate = zéro régression.
- Issues typées : progrès<plafond réarme ; progrès+plafond `AppError::TargetCeilingActive` (code `RENDEZVOUS_CEILING_ACTIVE`, non-retry-aveugle) ; vrai silence `AgentSessionError::Timeout` inchangé.
- Défaut secondaire (busy fantôme) : `mark_target_done_best_effort` sur toutes les branches d'abandon (PTY + structuré).
- Fichiers : application `{rendezvous.rs(new), service.rs, error.rs, lib.rs, orchestrator/mod.rs}`, infra `mcp/server.rs`, `app-tauri/state.rs` (+ les modifs infra inspector/lib pré-existantes du 1er fix).
- **Preuve réelle (re-vérifiée par Main dans le MAIN TREE)** : `cargo test -p application --lib` 75/0 (dont progressing_target_extends_then_resolves, _hits_ceiling_distinctly, silent_target_expires_no_reply, no_probe_falls_back_to_flat_window, ceiling_active_code) ; `cargo test -p infrastructure --lib` 247/0 ; clippy 0 nouveau warning.
## PROCHAINE ÉTAPE (reprise après relance IdeA)
1. **Rebuild AppImage EN COURS** (recette : `npm --prefix frontend run build` puis depuis `crates/app-tauri/` `APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 ../../frontend/node_modules/.bin/tauri build --bundles appimage` ; artefact `target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage` remplace `/home/anthony/Documents/IdeA_0.3.0_amd64.AppImage`, backup l'ancienne). Log build : scratchpad/rebuild.log.
2. **Utilisateur relance IdeA** (tue Main).
3. **Reprendre le test depuis T1** (skill). Le but immédiat = **re-valider T7 EN LIVE** : déléguer une charge réelle > 600 s en un long tour (la machine est rapide : `cargo clean && cargo build --release --workspace` en boucle jusqu'à >13 min, transcript en croissance) ⇒ ATTENDU = PAS de timeout à 600 s, extension, reply final livré. Puis enchaîner T8 (parallèles), T9 (transitif A→B→C, Architect+DevBackend froids), T10 (interruption + reconcile reboot).
4. **Si live vert : demander à Git de committer** le fix (cf. [[git-owns-commit-merge-decisions]]) ; rendez-vous MCP court marche (T2-T6), donc commit délégable à Git OU subagent natif.
Lié à [[rendezvous-600s-cap-too-short-heavy-tasks]], [[mcp-functional-test-plan-2026-06-24]], [[mcp-bridge-and-delegation-runtime-notes]].
</content>
</invoke>

View File

@ -1,29 +0,0 @@
---
name: checkpoint-mcp-tests-t1-t5-and-t5-livestate-defect
description: memory note checkpoint-mcp-tests-t1-t5-and-t5-livestate-defect
metadata:
type: project
---
---
name: checkpoint-mcp-tests-t1-t5-and-t5-livestate-defect
description: Run a6ced819 — relance complète T1→T6 du test fonctionnel MCP sur AppImage 08:41 (fix T5). T5 (live-state purgée sur no-reply) VALIDÉ EN LIVE. Blocage à T7 = défaut plafond 600s connu, non corrigé.
metadata:
type: project
---
# Checkpoint tests fonctionnels MCP — run a6ced819 (2026-06-24, relance depuis T1)
Binaire validé : **AppImage 2026-06-24 08:41:30** (fix live-state no-reply), process en cours = cette AppImage, git HEAD `1efe2f1`. Plan via skill **mcp-rendezvous-functional-test** (Main = demandeur). Voir [[mcp-functional-test-plan-2026-06-24]], [[rendezvous-600s-cap-too-short-heavy-tasks]], [[backstop-fires-on-intra-task-turn-rootcause]].
## Résultats de la relance T1→T6 (tous ✅)
- **T1** visibilité outils ✅ — 3 requesters chauds (Main, QA, DevFrontend) chacun pont ESTAB + 2 mcp-server ; froids (Architect, DevBackend, Git) 0 process.
- **T2** cible chaude (QA) ✅ — `pong` inline borné, workstate `done`, pas de busy fantôme.
- **T3** réveil à froid (Git) ✅ — nouveau pont (26012/26016), 1er tour `[IdeA·tâche…]` `parentUuid:null` intact, `delivered`, `pong-cold`.
- **T4** background node_id None (Git hors layouts.json) ✅ — `bg-step-ok`, multi-`delivered`, pont stable sans dup.
- **T5** no-reply backstop ✅ **VALIDÉ EN LIVE (le fix marche)** — Main libéré borné avec `TargetReturnedNoReply` (« returned to its prompt without calling idea_reply », retryable) ET **QA `status:"done"` purgée** (plus de busy fantôme `working`). Défaut historique #1 fermé.
- **T6** multi-étapes (QA lit fichier + `find` puis reply) ✅ — pas de libération prématurée, reply réel `header=… ; rs_count=55` (concorde avec `find` indépendant). Piège turn-watcher non déclenché.
## Blocage actuel : T7 (NON lancé — défaut connu non corrigé)
T7 = tâche lourde > plafond 600s. C'est le finding [[rendezvous-600s-cap-too-short-heavy-tasks]] : dépassement du plafond `IDEA_ASK_RENDEZVOUS_TIMEOUT_MS` (défaut 600000) → faux `-32001` + canal de report mort (idea_reply final non livrable), alors que la cible travaille et finit sur la branche. Les pistes (extension sur signe de vie / message « cible active, plafond atteint » distinct du retryable / plafond configurable / pas de cascade) sont **à cadrer Architect, pas encore implémentées**. Lancer T7 en live = figer Main ~10 min pour re-confirmer un défaut déjà documenté.
## Prochaine étape (décision utilisateur en attente)
Trois options sur T7 : (a) le lancer quand même pour re-confirmer (wedge ~10 min) ; (b) ouvrir le cycle de fix du plafond maintenant (Architect→Git→DevBackend→QA, rebuild, reprise T1) ; (c) sauter T7 et continuer T8 (parallèles), T9 (transitif A→B→C), T10 (interruption + reconcile reboot) qui ne dépendent pas du plafond. Architect/DevBackend restent froids pour T9.

View File

@ -1,98 +0,0 @@
---
name: checkpoint-orchestrator-designation-appimage-build
description: memory note checkpoint-orchestrator-designation-appimage-build
metadata:
type: project
---
# Checkpoint — AppImage rebuild après orchestrator-designation
Date: 2026-06-20
## État Git avant build
Git avait clôturé `feature/orchestrator-designation`:
- Commits atomiques créés:
- `287681c feat(orchestrator): ...`
- `e462136 feat(terminals): ...`
- `09f5362 docs: ...`
- `5ef001e chore(wip): ...`
- Merge local dans `develop`: `55d887f merge(orchestrator): intègre le chantier orchestrator-designation dans develop`.
- Branche `feature/orchestrator-designation` supprimée.
- Worktree propre à ce moment-là.
## Rebuild tenté
Commande initiale:
```bash
npm --prefix frontend run build && \
cd crates/app-tauri && \
APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 ../../frontend/node_modules/.bin/tauri build --bundles appimage
```
Résultat:
- Frontend build OK.
- Rust release build OK: `/home/anthony/Documents/Projects/IdeA/target/release/app-tauri`.
- AppDir généré: `/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA.AppDir`.
- Bundling Tauri KO: `failed to run linuxdeploy`.
## Contournement réussi
`appimagetool` extrait existait dans:
```text
/tmp/appimage_extracted_02f96dbd6ecc47f616b5a57fb8b7aa60/usr/bin/appimagetool
```
L'appel direct à appimagetool échouait car réseau restreint:
```text
Failed to download runtime ... pass it to appimagetool with --runtime-file
```
Runtime extrait depuis l'ancienne AppImage locale:
```bash
/home/anthony/Documents/IdeA_0.2.0_amd64.AppImage --appimage-offset
# 944632
dd if=/home/anthony/Documents/IdeA_0.2.0_amd64.AppImage \
of=/tmp/idea-appimage-runtime-x86_64 \
bs=1 count=944632 status=none
chmod +x /tmp/idea-appimage-runtime-x86_64
```
Commande finale réussie:
```bash
ARCH=x86_64 APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 \
/tmp/appimage_extracted_02f96dbd6ecc47f616b5a57fb8b7aa60/usr/bin/appimagetool \
--runtime-file /tmp/idea-appimage-runtime-x86_64 \
/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA.AppDir \
/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
```
Artefact produit:
```text
/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
Taille: 106M
--appimage-offset: 944632
```
## État Git après build
Le build/la session a laissé du runtime dirty:
```text
## develop...origin/develop [ahead 8]
M .ideai/conversations/6bc594e8-a37c-0dbd-1de6-6e3b73002cb4/handoff.md
M .ideai/conversations/6bc594e8-a37c-0dbd-1de6-6e3b73002cb4/log.jsonl
M .ideai/layouts.json
```
Ne pas nettoyer arbitrairement. Demander à Git de décider si ces fichiers runtime doivent être commités/ignorés au prochain passage.
## Important live
L'AppImage en cours d'exécution ne charge pas automatiquement ce nouvel artefact. Pour utiliser les correctifs d'orchestration/write-portal, lancer l'artefact 0.3.0 produit ci-dessus ou remplacer l'AppImage installée hors sandbox si nécessaire.

View File

@ -1,54 +0,0 @@
---
name: checkpoint-orchestrator-designation-backend-compile-fix
description: memory note checkpoint-orchestrator-designation-backend-compile-fix
metadata:
type: project
---
# Checkpoint — orchestrator-designation backend compile fix
Date: 2026-06-20
## Branche
`feature/orchestrator-designation`.
## Décision Git
Finir le chantier courant sur cette branche. Pas de stash, pas de switch. Après tests verts ou résidu qualifié: retour Git pour commits atomiques puis merge local vers `develop`.
## Incident live
La délégation vers Architect a été affichée dans son chat mais non soumise. Architect a été stoppé. Symptôme cohérent avec l'AppImage live qui n'intègre pas encore les correctifs WIP write-portal/headless delivery.
## Vérifications Main avant correction DevBackend
Verts:
- `cargo test -p infrastructure input --lib`: 35 passed.
- `cargo test -p application --test orchestrator_service`: 45 passed.
- `cd frontend && npx vitest run`: 41 files, 384 tests passed.
- `cd frontend && npx tsc --noEmit`: OK.
Rouge initial:
- `cargo test --workspace` ne compilait pas `crates/application/src/orchestrator/context_guard.rs`:
- `may_write_directly` appelé avec 2 args au lieu de 3 (`OrchestratorDesignation` manquant).
- mauvais champ `orchestrator` mis sur `ManifestEntry` au lieu de `AgentManifest`.
- init `AgentManifest` sans `orchestrator`.
## Correction DevBackend
DevBackend a modifié `crates/application/src/orchestrator/context_guard.rs`:
- `ProposeContext` charge `AgentManifest`, récupère `manifest.orchestrator_designation()`, puis appelle `may_write_directly(requester, &GuardedResource::ProjectContext, &designation)`.
- Le `FileGuard` reste un verrou, pas le propriétaire de l'autorisation.
- Tests locaux adaptés à `AgentManifest { version, entries, orchestrator }`.
Validations DevBackend:
- `cargo fmt --all && cargo test -p application --test orchestrator_service`: OK, 45 passed.
- `cargo test -p application`: OK.
- `cargo test --workspace`: compile maintenant plus loin mais échoue dans `app-tauri` sur tests loopback Unix socket sous sandbox (`PermissionDenied`/`Operation not permitted` lors du bind `/run/user/1000/idea-mcp/*.sock`).
## Prochaine étape
QA doit qualifier le résidu app-tauri:
- confirmer que les suites métier/orchestration sont vertes,
- confirmer si les échecs app-tauri sont environnement/sandbox et non régression,
- proposer la commande de validation acceptable ou le besoin de correction test/env.

View File

@ -1,42 +0,0 @@
---
name: checkpoint-orchestrator-designation-qa-verdict
description: memory note checkpoint-orchestrator-designation-qa-verdict
metadata:
type: project
---
# Checkpoint — QA verdict orchestrator-designation
Date: 2026-06-20
## Branche
`feature/orchestrator-designation`.
## Verdict QA
Chantier validable sous contrainte d'environnement. Pas de régression fonctionnelle liée à `context_guard.rs`.
## Commandes vertes qui font foi
- `cargo fmt --all -- --check`: OK.
- `cargo test -p application --test orchestrator_service`: OK, 45 passed.
- `cargo test -p application`: OK, suite application complète verte, incluant les tests context guard orchestrateur/proposition.
- `cargo test -p infrastructure input --lib`: OK, 35 passed.
- `cd frontend && npx vitest run`: OK, 41 files / 384 tests passed.
- `cd frontend && npx tsc --noEmit`: OK.
## Résidu app-tauri
- `cargo test -p app-tauri --lib`: rouge, 39 passed / 8 failed.
- `cargo test --workspace`: rouge sur le même bloc app-tauri.
Échecs exacts: tests loopback Unix socket:
- `mcp_bridge::tests::end_to_end_over_real_loopback`
- `state::bind_endpoint_d1_tests::rebind_after_corpse_socket_succeeds`
- `state::mcp_e2e_loopback_tests::*`
Cause qualifiée par QA: contrainte environnement/sandbox. Une sonde Node minimale échoue aussi à `listen()` sur Unix socket avec `EPERM` sous `/run/user/1000` et sous `/tmp`. Donc les tests qui exigent un vrai socket Unix ne sont pas exécutables dans ce sandbox.
## Prochaine étape
Retour à Git pour commits atomiques sur `feature/orchestrator-designation`, puis décision de merge local vers `develop` selon sa stratégie. Aucun push.

View File

@ -1,38 +0,0 @@
---
name: checkpoint-orchestrator-designation-restart
description: memory note checkpoint-orchestrator-designation-restart
metadata:
type: project
---
# Checkpoint — reprise chantier orchestrator-designation
Date: 2026-06-20
## Situation
L'utilisateur a demandé de terminer les chantiers ouverts. Main a repris le cycle proprement.
## Décision Git obtenue
Git a inspecté l'état local et décidé:
- Branche courante: `feature/orchestrator-designation`.
- Worktree dirty important mais analysé comme mono-thème: chantier orchestrateur/designation + diagnostic inter-agents.
- Ne pas stash, ne pas switch, ne pas ouvrir une nouvelle branche maintenant.
- Premier chantier à fermer: `orchestrator-designation` sur la branche actuelle.
- Après stabilisation + tests verts: retour à Git pour commits atomiques puis merge local vers `develop`.
- Ensuite seulement ouvrir des branches dédiées pour les autres chantiers.
## Incident de délégation
Main a tenté de demander à Architect de cadrer `orchestrator-designation` via `idea_ask_agent`.
L'utilisateur a interrompu et signalé qu'Architect était bloqué avec le texte de la tâche affiché dans son chat mais non envoyé.
Interprétation: symptôme cohérent avec les problèmes actuels de write portal / soumission physique PTY / délégation visible-background. Ne pas empiler de nouvelles délégations tant que cette zone n'est pas stabilisée.
## Prochaine reprise recommandée
1. Nettoyer/arrêter l'agent Architect bloqué si nécessaire.
2. Reprendre le chantier courant localement en lecture seule pour identifier exactement les changements WIP liés à la soumission de délégations.
3. Comme Main ne code pas, utiliser la délégation seulement vers un agent dont la soumission est confirmée fonctionnelle, ou lancer les agents en visible et vérifier qu'ils reçoivent réellement la tâche.
4. Priorité technique immédiate: fermer `orchestrator-designation`, car la délégation inter-agents fiable conditionne tous les autres chantiers.

View File

@ -1,38 +0,0 @@
---
name: checkpoint-rendezvous-redesign-devbackend-todo
description: memory note checkpoint-rendezvous-redesign-devbackend-todo
metadata:
type: project
---
# Checkpoint — Backstop no-reply : 1ère validation live ÉCHOUÉE → cause racine corrigée → RE-VALIDATION LIVE EN ATTENTE (MAJ 2026-06-23 ~19:40)
## Résultat du 1er test live (AppImage 0.3.0 du commit e87c05f) : ÉCHEC reproduisant le wedge
Scénario joué : DevBackend→QA `ping (test backstop)`, QA répond `pong` EN PROSE sans `idea_reply`.
- QA a bien émis un vrai `turn_duration durationMs=2218` (transcript, ts 17:23:40.161Z).
- MAIS `[turn-watcher] turn_ended` JAMAIS émis (`grep -c turn_ended` sur tout le log = **0**) → DevBackend resté coincé → rendez-vous Main→DevBackend a timeout 600s (MCP error -32001).
## CAUSE RACINE (prouvée) — encodage du slug projet Claude faux
Traces `[turn-watcher] arm` : toutes `conversation=<none>` + `baseline … count=0`. Le dossier transcript calculé n'existait pas :
- calculé (faux) : `…/-home-…-IdeA-.ideai-run-<uuid>` (point conservé) → `ls` = absent
- réel (disque) : `…/-home-…-IdeA--ideai-run-<uuid>` (DOUBLE tiret)
`encode_cwd` (crates/infrastructure/src/inspector/claude_paths.rs) ne remplaçait que `/`/`\\` et gardait le `.`. Claude Code encode `replace(/[^a-zA-Z0-9]/g,'-')`. Dir introuvable → conversation non résolue → baseline 0 → `turn_duration` jamais vu → backstop mort.
Log de référence : `/home/anthony/.local/share/app.idea.ide/logs/idea.log`.
## FIX LIVRÉ par DevBackend (NON commité — Git tranche)
- `encode_cwd` : `.map(|c| if c.is_ascii_alphanumeric() { c } else { '-' })` (algo exact Claude Code). `/IdeA/.ideai/run``-IdeA--ideai-run`.
- Test non-régression ajouté `encode_cwd_encodes_dot_in_run_dir_to_double_dash` (PASS). Test Windows maj `C:\\Users\\me``C--Users-me`.
- DevBackend précise : `count_turn_ends` agrège déjà tous les `.jsonl` du dossier ⇒ pas besoin de choisir un .jsonl ; `conversation=<none>` à l'armement est normal et sans impact une fois le dir correct.
## QA PRÉ-VALIDATION : VERTE
`cargo test --workspace` = **1616 passed, 0 failed** ; `cargo clippy --workspace --all-targets` = 0 erreur. Nouveau test + 5 tests turn-watcher tous PASS.
## EN COURS : rebuild AppImage (par Main, perms project-root OK)
Recette : `npm --prefix frontend run build` puis depuis `crates/app-tauri/` `APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 ../../frontend/node_modules/.bin/tauri build --bundles appimage`. Logs scratchpad fe-build.log / appimage-build.log. Sortie : `/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`.
## SEUL RESTE À FAIRE = RE-VALIDATION LIVE (garde-fou Git : pas de merge sans wedge prouvé levé EN LIVE)
1. Utilisateur remplace l'AppImage installée par la nouvelle + relance IdeA (coupe la session).
2. Session fraîche : rejouer DevBackend→QA pong-sans-`idea_reply`. ATTENDU cette fois : trace `arm … dir=…IdeA--ideai-run-… conversation=…` sur dossier EXISTANT + baseline NON nulle + `[turn-watcher] turn_duration detected … -> turn_ended` ⇒ libération du demandeur ~grâce (≈2s) avec résultat no-reply synthétique, et non-régression du chemin propre `idea_reply`.
3. Si VERT → demander à Git d'amender/committer le fix sur `feature/rendezvous-no-reply-backstop` puis décider du merge develop. Si KO → relayer trace réelle à DevBackend.
## Trou produit confirmé (hors scope, à planifier)
Au reboot, `.ideai/live-state.json` non réconcilié : agents restent `working` fantôme (process morts). Fichier file-guardé, `idea_workstate_set` = self only, aucun reset cross-agent. Manque : réconciliation au boot OU outil orchestrateur de reset.

View File

@ -1,34 +0,0 @@
---
name: checkpoint-t1-wake-delivery-bug-fixed-rebuild-pending
description: memory note checkpoint-t1-wake-delivery-bug-fixed-rebuild-pending
metadata:
type: project
---
---
name: checkpoint-t1-wake-delivery-bug-fixed-rebuild-pending
description: Ticket #1 — T1 VERT live. T3 root cause = tâches de fond jamais projetées dans work-state ; fix BE+FE livré unit-green ; rebuild AppImage en cours ; reste re-QA live T3 + T2 reboot, puis merge.
metadata:
type: project
---
# Checkpoint ticket #1 — état au 2026-07-03
## T1 — VERT (validé live QA)
Wake auto du propriétaire à la complétion + `completionDelivered: true` prouvés dans le store (`.ideai/background-tasks/<owner>.json`, task `02aa2493`). Fixes portant T1 (unit-green, NON commités) : wake.rs:119 (mark_completion_delivered dès session.send accepté), structured.rs:121 (drain_reply_stream_with_readiness), agent_wake.rs:504 (régression), + itér.1 MediatedInbox enqueue FIFO sans busy.
Note : `idea_workstate_read` n'expose PAS les BackgroundTasks — lire le store JSON.
## T3 — root cause trouvée + fix livré (unit-green, NON commité)
Défaut live : aucun bouton Cancel/Retry dans le panneau Work. Cause = le DTO `AgentWorkState` ne portait pas les tâches de fond et `GetProjectWorkState` n'avait pas de dépendance BackgroundTaskStore → `agent.backgroundTasks` toujours vide en live → section masquée (ProjectWorkStatePanel.tsx:638). Front déjà câblé, seule la projection backend manquait. Vitest verts en trompe-l'œil (payload mocké).
Cadrage Architect : mémoire `workstate-background-tasks-projection-fix` (Option A — étendre le read-model unique, best-effort, aucun nouveau port).
Livré :
- BE (DevBackend) : VO `AgentBackgroundTaskState` + champ `background_tasks` sur AgentWorkState + builder `with_background_tasks` + projection union open/undelivered best-effort (workstate/mod.rs) ; DTO Tauri backgroundTasks (dto.rs) ; wiring state.rs. Tests : `cargo test -p application` 24 passed (workstate.rs), `-p app-tauri` vert, build workspace OK.
- FE (DevFrontend) : mapping queued/waiting→pending explicité, test sur vrai shape backend, + correctif tri (finishedAtMs jamais émis → bascule sur updatedAtMs). vitest 460/460, build OK. Verdict : `tickets-t3-frontend-validation-verdict`.
- Dette de contrat tracée en ticket #5 (summary non affiché, owner/project inutiles). Low.
## RESTE À FAIRE (ordre)
1. Rebuild AppImage `NO_STRIP=true` — EN COURS (background bixa34tht). Voir [[appimage-build-no-strip-relr-dyn-fix]].
2. Utilisateur relance l'AppImage.
3. QA re-passe T3 LIVE : T3-a apparition running + Cancel actif ; T3-b Cancel agit → cancelled + Retry actif ; T3-c Retry → nouvelle tâche running ; T3-d borne livraison (tâche livrée disparaît = conforme V1, PAS un bug) ; T3-e isolation par agent ; T3-f non-régression live/busy/tickets. Détail dans cadrage Architect.
4. T2 — reconcile après reboot (fin AVANT wake), protocole MANUEL, coordination reboot utilisateur.
5. Si T1+T2+T3 verts → Git commit de TOUS les fix (T1 + T3 BE/FE) + merge feature/background-tasks-first-class → develop (résorbe aussi 4 tests protocole MCP périmés rouges sur develop).
Liens : [[workstate-background-tasks-projection-fix]], [[tickets-t3-frontend-validation-verdict]], [[b8-in-app-trigger-run-in-background]], [[background-tasks-first-class-design]].

View File

@ -1,34 +0,0 @@
---
name: checkpoint-work-tab-blank-fix
description: memory note checkpoint-work-tab-blank-fix
metadata:
type: project
---
# Checkpoint — Fix onglet Work vide
Date: 2026-06-21
## État final
Correctif frontend de l'onglet Work vide terminé, validé QA (VERT) et mergé localement dans `develop`.
- `develop` @ `a66881d` — merge local `--no-ff` du fix.
- Commit de feature intégré : `3e1e553` (anciennement `9d2f186`, message amendé pour retirer le marqueur `(WIP, QA en attente)`).
- Branche `fix/work-tab-blank-page` supprimée après merge.
- Aucun push, aucune PR. `develop` en avance de 45 commits sur `origin/develop` (local-only).
## Contenu du fix
Normalisation défensive du work-state (`frontend/src/adapters/workStateNormalization.ts` nouveau) + adaptation panneau/mock/tests, pour qu'un work-state partiel/inattendu ne rende plus une page entièrement vide. 5 fichiers, +259/-47.
## QA verte (sortie réelle)
- `cd frontend && npx tsc --noEmit` → exit 0.
- `cd frontend && npx vitest run` → 42 fichiers / 407 tests passed, exit 0.
## Branches ouvertes restantes (non mergées dans develop)
À cadrer/arbitrer avant intégration :
- `feature/agent-skills` @ `ef101db` — domaine skills agent + use cases + FS store + injection LaunchAgent (L12).
- `feature/agent-skill-awareness` @ `5be8987` — manifeste skills + outil MCP `idea_skill_read` + brief « capacités IdeA » dans contexte agent ; contient aussi un fix input cold-start (`e93a2c1`).
- `fix/cold-start-delivery-race` @ `9590eac` — fix livraison délégation cold-start ; branche basée sur d'anciens commits release (0.1.0/0.2.0), potentiellement redondante avec `e93a2c1` de skill-awareness → vérifier avant merge.

View File

@ -1,64 +0,0 @@
---
name: checkpoint-workstate-controlled-actions-lot-d
description: memory note checkpoint-workstate-controlled-actions-lot-d
metadata:
type: project
---
# Checkpoint — Workstate controlled actions Lot D
Date: 2026-06-20
## État final
Lot D `workstate controlled actions` terminé, validé QA et mergé localement dans `develop`.
Branche finale:
- `develop` @ `c1e99d1` — merge local `feature/workstate-controlled-actions`.
- `feature/workstate-controlled-actions` conservée.
- Aucun push, aucune branche supprimée.
- Working tree propre après décision Git.
## Commits créés
- `3408c96``feat(workstate): actions contrôlées sur le work-state (Lot D backend)`
- Use cases agent-level `AttachLiveAgent` et `StopLiveAgent`.
- Commandes Tauri `attach_live_agent` et `stop_live_agent`.
- Attach rebind PTY/structured sans spawn; stop PTY/structured.
- DTO camelCase et wiring AppState/lib.
- `1c6441b``feat(workstate): UI des actions contrôlées (Lot D frontend)`
- Port/adaptateur agent alignés sur le nouveau contrat attach + stop.
- Panneau Work: Open, Attach, Stop, View conversation, Copy summary.
- Work n'appelle pas `launchAgent`; Stop passe par `stopLiveAgent`; View/Copy n'utilisent que les previews Lot C.
- `0976648``chore(wip): état runtime .ideai (flux conversation live)`
- Runtime isolé des commits feature.
- `c1e99d1` — merge local dans `develop`.
## QA verte
Commandes QA/Git validées:
- `cargo fmt --all -- --check` OK.
- `cargo test -p application --test workstate_actions` OK, 7 passed.
- `cargo test -p application --test workstate` OK, 21 passed.
- `cargo test -p app-tauri --test dto_agents` OK, 25 passed.
- `cargo test -p app-tauri --test list_live_agents_r0b` OK, 5 passed.
- `cargo check -p app-tauri` OK.
- `cd frontend && npx vitest run src/features/workstate/workstate.test.tsx src/features/projects/projects.test.tsx` OK, 25 tests.
- `cd frontend && npx vitest run src/adapters/agent.test.ts` OK, 8 tests.
- `cd frontend && npx vitest run src/features/layout/singletonAgent.test.tsx src/features/layout/agentAlreadyRunning.test.tsx` OK, 9 tests.
- `cd frontend && npx tsc --noEmit` OK.
Warnings restants uniquement côté Vite sur options `esbuild` dépréciées/ignorées au profit de `oxc`, non bloquants.
## Décisions produit/techniques
- Actions Lot D opèrent seulement sur l'état existant; pas de lancement d'agent neuf depuis Work.
- Attach ne crée ni session ni cellule; cible déterministe = cellule visible vide côté UI.
- Stop ne supprime ni agent, ni tickets, ni handoff/conversation summary.
- View/Copy restent limités aux previews bornées Lot C; aucun log brut exposé.
## Suite probable
La quadrilogie Work A/B/C/D est intégrée. Prochains chantiers restants à cadrer: persistance conversationnelle/cross-profile plus profonde, mise à jour automatique mémoire/contexte pendant la vie des agents, ou synchronisation documentaire architecture selon priorité Architect/Main.

View File

@ -1,60 +0,0 @@
---
name: checkpoint-workstate-conversation-summaries-lot-c
description: memory note checkpoint-workstate-conversation-summaries-lot-c
metadata:
type: project
---
# Checkpoint — Workstate conversation summaries Lot C
Date: 2026-06-20
## État final
Lot C `workstate conversation summaries` terminé, validé QA et mergé localement dans `develop`.
Branche finale:
- `develop` @ `6e1ba7e` — merge local `feature/workstate-conversation-summaries`.
- `feature/workstate-conversation-summaries` conservée.
- Aucun push, aucune branche supprimée.
- Working tree propre après décision Git.
## Commits créés
- `e9edadc``feat(workstate): résumés de conversation dans le read-model (Lot C backend)`
- `ProjectWorkState.conversations` top-level.
- Résumés best-effort depuis `HandoffStore`, fallback `ConversationLog::last(3)`.
- Déduplication des conversation ids issus des tickets, ordre first-seen.
- DTO camelCase et câblage Tauri.
- `c50622e``feat(workstate): UI des résumés de conversation (Lot C frontend)`
- Types TS `ConversationWorkSummary` et previews.
- Mock normalise `conversations: []`.
- Panneau Work joint `tickets[].conversationId` vers `conversations[]` et affiche badge + preview compacte.
- `78500d8``chore(wip): état runtime .ideai (flux conversation live)`
- Runtime isolé des commits feature.
- `6e1ba7e` — merge local dans `develop`.
## QA verte
Commandes QA finales validées:
- `cargo fmt --all -- --check` OK.
- `cargo test -p application --test workstate` OK, 21 passed, aucun warning Rust.
- `cargo test -p app-tauri --test dto_agents` OK, 21 passed.
- `cargo check -p app-tauri` OK.
- `cd frontend && npx vitest run src/features/workstate/workstate.test.tsx src/features/projects/projects.test.tsx` OK, 2 files / 19 tests.
- `cd frontend && npx tsc --noEmit` OK.
Warnings restants uniquement côté Vite sur options `esbuild` dépréciées/ignorées au profit de `oxc`, non bloquants.
## Décisions produit/techniques
- Source primaire: handoff conversationnel existant.
- Fallback: derniers tours bornés du log, jamais le log brut complet.
- Read-only et best-effort: les erreurs de preview ne bloquent pas `live/busy/tickets`.
- Pas de nouvelle persistance, pas de mutation/réparation, pas de nouvelle action UX.
## Suite probable
Le prochain lot logique est Lot D: actions UX read/write contrôlées autour du panneau Work (ouvrir/rattacher cellule, voir conversation, arrêter agent, éventuellement copier résumé), à cadrer par Architect avant implémentation.

View File

@ -1,62 +0,0 @@
---
name: checkpoint-workstate-delegation-queue-lot-b
description: memory note checkpoint-workstate-delegation-queue-lot-b
metadata:
type: project
---
# Checkpoint — Workstate delegation/queue snapshot Lot B
Date: 2026-06-20
## État final
Lot B `workstate delegation/queue snapshot` terminé, validé QA et mergé localement dans `develop`.
Branche finale:
- `develop` @ `64c2c14` — merge local `feature/workstate-delegation-queue`.
- `feature/workstate-delegation-queue` conservée.
- Aucun push, aucune branche supprimée.
- Working tree propre après décision Git.
## Commits créés
- `cc7d99a``feat(workstate): snapshot des délégations en file par agent (Lot B backend)`
- `QueuedTicketSnapshot` + port read-only `AgentQueueSnapshot`.
- Impl `InMemoryMailbox` snapshot FIFO sans cloner les senders.
- `GetProjectWorkState.agents[].tickets` avec statut dérivé `inProgress/queued`, source `human/agent`, preview bornée.
- DTO Tauri camelCase et wiring `AppState` avec le même mailbox partagé en deux ports.
- `c600604``feat(workstate): UI des délégations en file par agent (Lot B frontend)`
- Types TS `AgentTicketState`, `TicketWorkStatus`, `TicketWorkSource`.
- Mock gateway normalise `tickets: []`.
- Panneau Work affiche les tickets FIFO, source Human/Agent, preview, ticket court.
- Refresh ajouté sur `delegationReady`.
- `5cb99fd``chore(wip): état runtime .ideai (flux conversation live, layouts)`
- Runtime isolé des commits feature.
- `64c2c14` — merge local dans `develop`.
## QA verte
Commandes QA réelles validées:
- `cargo fmt --all -- --check` OK.
- `cargo test -p infrastructure mailbox --lib` OK, 13 passed.
- `cargo test -p application --test workstate` OK, 12 passed.
- `cargo test -p app-tauri --test dto_agents` OK, 20 passed.
- `cargo check -p app-tauri` OK.
- `cd frontend && npx vitest run src/features/workstate/workstate.test.tsx src/features/projects/projects.test.tsx` OK, 2 files / 17 tests.
- `cd frontend && npx tsc --noEmit` OK.
- QA ajoutée: `cargo test -p domain mailbox --lib` OK, 6 passed.
Warnings observés uniquement côté Vite sur options `esbuild` dépréciées/ignorées au profit de `oxc`, non bloquants.
## Décisions produit/techniques
- Les tickets `human` et `agent` sont inclus dans le snapshot; l'UI distingue explicitement `Human` vs agent/requester au lieu de tout appeler délégation agent.
- Le statut est dérivé à la lecture: `inProgress` si le ticket courant correspond au `busy_state`, sinon `queued`.
- Pas de nouvelle persistance, pas de lecture `log.jsonl`/handoff, pas d'événement `agentQueueChanged`, pas d'action UX d'annulation/résolution.
## Suite probable
Le prochain lot logique du chantier UX conversations/délégations est Lot C: résumés de conversations depuis log/handoff en lecture best-effort, ou Lot D actions UX selon priorité produit. Suivre le cycle Main: Architect -> Git -> DevBackend/DevFrontend -> QA -> Git.

View File

@ -0,0 +1,41 @@
---
name: codex-network-access-config-fix
description: memory note codex-network-access-config-fix
metadata:
type: project
---
# Correctif accès réseau Codex via `sandbox_workspace_write.network_access`
Le 2026-07-26, le diagnostic live a montré qu'un agent Codex lancé par IdeA échouait sur `curl` même avec IP forcée. La cause n'était pas seulement DNS ni une session à relancer : Codex CLI 0.145 attend la configuration officielle `sandbox_workspace_write.network_access=true` pour autoriser le réseau dans `workspace-write`.
Correctif implémenté et validé par QA dans les sources :
- Projection Codex `$CODEX_HOME/config.toml` : gérer `[sandbox_workspace_write] network_access = true/false` via `MergeToml`, pour éviter un stale `true`.
- `codex exec` structuré : passer `-c sandbox_workspace_write.network_access=<bool>` quand la policy est connue.
- La permission système IdeA reste séparée des permissions fichiers/bash : seul `NetworkPolicy::Allow` active `network_access=true`; `Deny`, `Ask` et `None` donnent `false`.
- L'env `CODEX_SANDBOX_NETWORK_DISABLED` est encore upserté comme garde anti-héritage stale, mais ce n'est plus le mécanisme principal.
Fichiers principaux :
- `crates/infrastructure/src/permission/codex.rs`
- `crates/domain/src/ports.rs`
- `crates/application/src/agent/lifecycle.rs`
- `crates/infrastructure/src/session/codex.rs`
- `crates/application/src/ticket_assistant.rs`
Validation QA verte :
- `cargo test -p infrastructure permission::codex`
- `cargo test -p infrastructure codex_`
- `cargo test -p application --test agent_lifecycle codex_`
- `cargo test -p application --test ticket_assistant codex_`
- `cargo test -p domain`
Build réalisé :
- `npm --prefix frontend run build` : vert.
- `tauri build --bundles appimage` : compilation release OK, mais bundling linuxdeploy a échoué car `appimagetool` tentait de télécharger le runtime sans réseau.
- Contournement appliqué : `appimagetool --runtime-file /home/anthony/.cache/tauri/runtime-x86_64 ...`.
- AppImage générée : `target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`, SHA-256 `08d74dfe950312f968f3fe5646d747f2ac6fa25f2a523a83825182f2809e2aa8`.
Validation live restante obligatoire : relancer IdeA depuis cette nouvelle AppImage, lancer un agent Codex frais avec `network: allow`, puis exécuter un vrai `curl`. La session Codex déjà active ne peut pas prouver le fix car elle a été lancée avant ces nouveaux arguments/config.

View File

@ -0,0 +1,59 @@
---
name: context-agent-token-offload-design
description: memory note context-agent-token-offload-design
metadata:
type: project
---
# Agent Context — allègement token, périmètre figé
Décision validée le 2026-07-23 : un nouvel agent **Context**, tournant sur un **LLM local peu
puissant**, a été ajouté au projet IdeA pour réduire la fréquence des limites de tokens atteintes
par les autres agents (Main, Architect, UX, DevBackend, DevFrontend, QA, Git) — **sans dégrader
la qualité de leurs décisions**.
## Périmètre retenu (mécanique, faible risque)
- Recherche de symboles (localisation définition/usage).
- Résumé de fichier(s) — factuel, pas d'interprétation architecturale.
- Classification d'erreurs de compilation (tri d'un log brut).
- Extraction des tests en échec (à partir d'une sortie de test brute).
- Résumé de diff (`git diff` volumineux → liste factuelle de fichiers/nature de changement).
- Repérage de fichiers probablement concernés par un ticket (piste, pas garantie).
## Explicitement exclu / dégradé en brouillon uniquement
Proposer un message de commit, générer un test unitaire, mettre à jour une documentation qui fait
foi : ce sont des artefacts qui engagent une décision et qui appartiennent aux agents propriétaires
(Git pour les commits, QA pour les tests). Un modèle local faible qui les produit comme livrable
ferait courir un risque de qualité que la vérification par l'agent fort annulerait de toute façon
le gain de tokens visé. Context peut produire un brouillon explicitement marqué comme tel, jamais
un livrable.
## Garde-fous de fiabilité (vu la faiblesse du modèle)
Context ne décide rien, ne corrige pas de code de production, ne remplace jamais une vérification
qui doit être prouvée (tests QA, verdict de build), et ne devine jamais quand l'information manque
— il doit dire "non trouvé"/"incertain" plutôt qu'extrapoler. Réponses courtes, structurées,
citant ce qui a été effectivement vu (chemins, lignes), sans jugement de valeur.
## Où c'est câblé
- Contexte agent : `.ideai/agents/context.md` (écrit via `idea_update_context`).
- Template global IdeA créé : « Context — Agent d'assistance légère à faible coût »
(`defaultProfileId` = profil LLM local de l'agent Context), pour réutilisation cross-projet.
Le template ne contient que la partie générique (aucune référence à IdeA le produit) ;
la déclaration des 7 autres rôles nommés reste project-spécifique et vit dans
`.ideai/agents/context.md` du projet, pas dans le template.
- Rôle ajouté à la liste des rôles du contexte projet global (CLAUDE.md §3) : Context ne fait
**pas** partie du cycle obligatoire (§4) — pas d'étape qui lui est dédiée, il est sollicité en
support ponctuel par n'importe quel agent.
- Chaque agent (Main, Architect, DevBackend, DevFrontend, QA, Git, UX) a reçu un ajout court dans
sa section « Délégation & collaboration » expliquant quand solliciter Context et rappelant que
son résultat est une piste à vérifier, jamais une conclusion ou une décision.
## Pourquoi
Voir [[idea-product-directives-main-handoff]] pour les directives produit générales ; cette note
couvre spécifiquement le compromis coût-tokens/qualité qui a motivé le périmètre volontairement
restreint de Context (pas de délégation de jugement, seulement de compression/extraction
factuelle).

View File

@ -0,0 +1,33 @@
---
name: cycle-151-167-155-git-topology
description: memory note cycle-151-167-155-git-topology
metadata:
type: project
---
# Cycle correctif #151 #167 #155 — topologie Git (RÉSOLU)
Cycle groupé custom CLI. Décision Git rendue/exécutée le 2026-08-06.
## Issue finale
- **#151 (z-order Cancel) : CLOSED** — mergé dans develop, QA verte.
- **#167 (ordre événements avant Final) : CLOSED** — mergé dans develop, QA verte (backend `codex_send_with_tap...ok` + frontend 38/38 confirmés sur develop).
- **#155 (clipboard paste) : OUVERT** — partiel. Logique+tests verts, mais e2e presse-papiers natif Tauri/AppImage non validable dans l'env. Code NON mergé dans develop.
## Commits
- `3d4ea685` chore(tickets): rouverture #151 #155 + création #167 (sur develop, début cycle)
- `b45deabe` **C1** fix(cli): z-order Cancel #151 + projection live événements #167 (+ résidu fixture #165/#166) — QA verte → **mergé**
- `388de4b8` **C2** fix(cli): collage presse-papiers clipboardData.files #155 (partiel) → **non mergé**
- `9f05ad6a` merge(cli): intègre #151 #167 (QA verte) — --no-ff sur develop
- `0390d182` chore(tickets): clôture #151 #167 — sync miroir
## Branches
- `develop` : intègre #151 #167 (pas #155). En avance sur origin/develop, **pas de push**.
- `fix/cycle-151-167-155-custom-cli` : ramenée à C1 (b45deabe), mergée dans develop.
- `wip/155-clipboard-paste-e2e` : préserve C1+C2 (388de4b8) → porte le code #155 pour le cycle de clôture e2e AppImage.
## Point de clôture #155
Valider le collage presse-papiers image/fichier sur l'AppImage réelle. Reprendre depuis `wip/155-clipboard-paste-e2e`.
## Notes
- `reset --hard` a révoqué hors-cycle les modifs miroir disque non committées (carnets QA, `.ideai/idea-android-plugin.json`) ; le store IdeA reste source de vérité, miroirs resyncés à la clôture. La modif 1-ligne `idea-android-plugin.json` (propriétaire inconnu) a été perdue du working tree — à refaire si besoin.
- Le toolchain Rust du shell n'a pas de default ; backend confirmé via cargo nightly sous `.ideai/run/<agent>/.opencode/.rustup`.

View File

@ -1,16 +0,0 @@
---
name: f35-launch-status-done-config-crud-blocked
description: F35.1 UI statut de lancement du serveur local livrée+verte ; F35.2 config CRUD bloquée sur un DTO figé qui ne matche pas le wire réel + delete manquant.
metadata:
type: project
---
Ticket #35 sur `feature/modeles-locaux`.
**F35.1 LIVRÉ (vert)** : événements `model_server_status_changed`/`agent_launch_failed` déjà exposés via `domain://event`. Consommés dans `useAgents``modelServerStatusByServer` (par serverId) + `launchFailureByAgent` (par agentId). Badge `ModelServerLaunchBadge` monté par ligne dans `AgentsPanel`, corrélé via `profile.opencode.localModelServerId`. Contrat réel ≠ DTO figé du ticket : `serverId` sur l'enveloppe (pas par état) ; états camelCase `notConfigured|probing|starting|ready{reused}|failed{code,message}` ; PAS de `baseURL`/`model` émis dans le statut. Je me suis aligné sur le wire réel.
**F35.2 BLOQUÉ — 3 gaps backend remontés à Main :**
1. (bloquant) `save_model_server`/`list_model_servers` transmettent le domaine `LocalModelServerConfig` en `serde(transparent)`, forme IMBRIQUÉE : `{id, kind:"llamaCpp", name, endpoint:{baseURL,port}, model:{id,label,path?,servedName}, binary?, args, autoStart, stopPolicy}`. Le DTO figé du ticket est plat et FAUX (kind "llamacpp", baseURL/port/modelPath/servedModelName/binaryPath à plat). Pire : `model` exige `id`+`label` non-vides (LocalModelRef::new) absents du DTO figé → payload figé rejeté. Besoin arbitrage Architect : (A) couche DTO plate app-tauri qui remplit model.id/label, ou (B) MAJ du DTO figé vers la forme imbriquée + sémantique de model.id/label.
2. Pas de commande `delete_model_server`.
3. (côté moi) créer `ModelServerGateway`/port/adapter une fois le contrat tranché.
Saisie simple de `localModelServerId` (F36) laissée en place, pas de régression. tsc propre ; suite 593/593.

View File

@ -0,0 +1,14 @@
---
name: frontend-uses-npm-not-pnpm
description: memory note frontend-uses-npm-not-pnpm
metadata:
type: project
---
Le dossier `frontend/` s'installe et se build avec **npm**, jamais pnpm (lockfile `package-lock.json`).
**Ne jamais lancer `pnpm` (ni `corepack pnpm build`, ni le wrapper `pnpm --dir frontend build`) dans `frontend/`** :
- `pnpm --dir frontend build` échoue d'abord sur un pré-check `pnpm install` (`ERR_PNPM_IGNORED_BUILDS` sur esbuild).
- Surtout, `pnpm install` **clobber** le `node_modules` npm : pnpm aplatit `vite@5.4.21` au top-level alors que `vitest@4.1.x` exige `vite ^6||^7||^8`. Résultat : `ERR_PACKAGE_PATH_NOT_EXPORTED: './module-runner'` dès que vitest spawn son worker pool (>3 fichiers de test). Avec npm, `vite@8` est imbriqué sous `node_modules/vitest/node_modules/vite`, donc tout marche.
- Réparation si le clobber arrive : `rm -f frontend/pnpm-lock.yaml frontend/pnpm-workspace.yaml && cd frontend && npm install`, puis `git checkout -- frontend/package-lock.json`.
Commandes correctes sans le wrapper cassé : `cd frontend && npx tsc --noEmit && npx vite build` (build) et `npx vitest run` (tests). Le script `pnpm build` du package.json ne doit pas être utilisé tel quel dans cet environnement.

View File

@ -0,0 +1,19 @@
---
name: idea-distribution-strategy-desktop-vs-docker
description: memory note idea-distribution-strategy-desktop-vs-docker
metadata:
type: project
---
Stratégie de distribution IdeA validée utilisateur (2026-07-16, suite #13) : DEUX offres au-dessus du MÊME cœur backend (pas de fork métier).
**Offre 1 — Full desktop** : binaire Tauri `app-tauri` actuel. AppImage Linux (existe, inchangée). Windows explicitement REPORTÉ (garder la portabilité à l'esprit, ne rien introduire de non-portable ; PTY = ConPTY à retester le jour venu). L'AppImage reste desktop PUR — elle ne bundle pas les assets web.
**Offre 2 — Serveur/client** : image Docker, bâtie sur un binaire serveur HEADLESS `idea-serve` SANS dépendance Tauri/WebKit (pas de dockerisation du binaire Tauri qui traînerait GTK/WebKit pour rien). Cadré faisable en hexagonal par Architect.
**Point pivot technique** : `server.rs` vit dans `crates/app-tauri` et réutilise indirectement la présentation Tauri via `crate::state::AppState`, `crate::dto::*`, `crate::events::DomainEventDto`, `crate::pty::PtyChunk`, `crate::mcp_endpoint::*`, `ResumeContext`. Le protocole HTTP/WS lui est déjà autonome. Le vrai travail = découpler les DTO (→ crate partagé `presentation-dto`/`backend-api`) puis extraire `crates/web-server` (sur `BackendCore`, pas `AppState`) puis le bin `idea-serve`.
**Tickets** : #65 (headless, high, L1 DTO→L2 web-server→L3 idea-serve), #66 (Docker, medium, L4 build web http→L5 Dockerfile volumes /data+/workspace→L6 agents CLI conteneur), #64 (folder browser web, dependsOn #66 pour /workspace), #67 (lock inter-process app-data-dir, low).
**Topologie de branches (décision utilisateur)** : chantier packaging sur `feature/server-client-packaging` (créée depuis `c246875`, tête de `feature/ticket13-pty-websocket`). PAS de merge dans develop tant que l'utilisateur n'a pas validé lui-même la NON-RÉGRESSION desktop-only. Flux final : `feature/server-client-packaging``feature/ticket13-pty-websocket``develop`. Git rebase la branche packaging si #13 avance.
Invariants : desktop AppImage ne perd RIEN ; aucun import Tauri dans le bin headless ; même cœur/use cases/stores ; contrat HTTP/WS inchangé sauf lot versionné. Voir [[frontend-uses-npm-not-pnpm]], [[appimage-build-no-strip-relr-dyn-fix]].

View File

@ -1,47 +0,0 @@
---
name: mcp-e2e-findings-reply-wedge-phantom-busy
description: memory note mcp-e2e-findings-reply-wedge-phantom-busy
metadata:
type: project
---
---
name: mcp-e2e-findings-reply-wedge-phantom-busy
description: Findings validation MCP e2e live (AppImage 0.3.0) — transport/rendez-vous SAINS ; un seul vrai défaut = wedge si l'agent délégué n'appelle pas idea_reply (pas de timeout serveur).
metadata:
type: project
---
# Findings validation MCP e2e (live, AppImage 0.3.0) — 2026-06-22
Contexte : validation réelle du parcours inter-agents (cf. [[resume-after-appimage-rebuild-mcp-e2e]]). Méthode = Main observe en externe (Bash sur `ss -xp` + transcripts `~/.claude/projects/<run-dir-encodé>/*.jsonl`), l'utilisateur déclenche dans l'UI ; on ne valide PAS via `idea_ask_agent`.
## Scénario 1 — délégation vers agent FROID + cycle complet : VERDICT
-**Réveil à froid** : déléguer vers un agent arrêté relance son pont (`mcp-server --requester <id>` réapparaît, socket ESTAB recompte).
-**1er tour non perdu** : tâche livrée intacte = 1er `user` `[IdeA · tâche de <agent> · ticket <uuid>] …`.
-**Chemin positif `idea_reply`** : quand l'agent cible appelle `idea_reply(ticket,result)`, le bridge répond `reply ... delivered`, le **demandeur reçoit le `tool_result` et reprend la main** (vérifié : DevBackend reçoit `pong` puis continue).
-**Purge live-state** : dès l'`idea_reply`, `idea_workstate` repasse le cible de `working``done`, intent vidé.
➡️ **Transport + protocole de rendez-vous = SAINS.** Bugs historiques 3/4/5 OK sur ce chemin.
## LE défaut restant (racine unique) — wedge sans `idea_reply`
Si l'agent délégué **termine son tour sans appeler `idea_reply`** (ex. tâche triviale « réponds pong » → il répond `pong` en **prose** et s'arrête) :
- le **demandeur wedge indéfiniment** dans `idea_ask_agent` (transcript demandeur figé sur le `tool_use` idea_ask_agent, aucun `tool_result`) ;
- la **cible reste `working`** sur le ticket périmé dans la live-state ;
- **aucun timeout ni récupération** côté serveur. Une interruption utilisateur du `ask` libère le demandeur mais **ne purge pas** le `working` de la cible (purge seulement à l'`idea_reply`).
➡️ Le « Busy fantôme » n'est PAS un bug d'état indépendant : c'est la **conséquence** de l'absence d'`idea_reply`. Une seule cause à traiter.
### Pistes correctif (à arbitrer Architect)
1. **Durcir contextes agents** : « toute tâche déléguée se termine IMPÉRATIVEMENT par `idea_reply`, même triviale » (cheap, attaque la cause comportementale).
2. **Garde-fou serveur (rendez-vous)** : timeout sur l'attente `idea_ask_agent` → renvoyer au demandeur un résultat d'échec/relance explicite + purger le `working` de la cible (idempotent). Touche le contrat rendez-vous + cycle de vie live-state = domaine Architect. Voir [[idea-program-surface-separation-and-livestate]], [[mcp-bridge-and-delegation-runtime-notes]].
## Diagnostic / repro (rappels)
- Ponts : `pgrep -af 'mcp-server --endpoint'` (1 requester = 2 process) ; `ss -xp | grep -c idea-mcp`.
- Reply réel = `tool_use` `idea_reply` dans le transcript cible → tool_result `reply ... delivered` (⚠️ ne pas confondre avec les mentions `idea_reply` du CLAUDE.md injecté via attachments).
- Wedge demandeur = transcript demandeur s'arrête sur `tool_use` `idea_ask_agent` sans `tool_result`.
- ⚠️ Horodatages transcripts = **UTC** ; `ls %H:%M:%S` masque la date → comparer avec `date` + mtime réel (`ls -t`).
## Restant à tester (scénarios e2e suivants)
- Délégation vers agent BACKGROUND (node_id None) — même protocole, vérifier pas de 1er tour perdu.
- `ask` sans réponse ne wedge pas durablement la CONNEXION du demandeur (vs juste l'appel) — Bug 5 côté transport.
- Profils Claude/Codex utilisent MCP par défaut ; fallback fichier+prose cohérent.
- Observabilité UI des délégations/replies (aujourd'hui opaque) — sujet UX.

View File

@ -1,45 +0,0 @@
---
name: mcp-functional-test-plan-2026-06-24
description: memory note mcp-functional-test-plan-2026-06-24
metadata:
type: project
---
---
name: mcp-functional-test-plan-2026-06-24
description: Plan de test FONCTIONNEL du rendez-vous inter-agents MCP (trivial→tordu), à exécuter après rebuild develop HEAD ; méthode, ordre, setup IdeA et critères de réussite.
metadata:
type: project
---
# Plan de test fonctionnel MCP inter-agents (2026-06-24, run a6ced819)
Objectif : état des lieux par tests **fonctionnels** (pas unitaires) du rendez-vous `idea_ask_agent``idea_reply`, du trivial au plus tordu. On lance dans l'ordre, on **s'arrête au 1er blocage**, on corrige (cycle Architect→Git→Dev→QA), rebuild+relance, puis on **reprend de T1**. Contexte/historique : [[mcp-e2e-findings-reply-wedge-phantom-busy]], [[backstop-fires-on-intra-task-turn-rootcause]], [[rendezvous-no-reply-backstop-design]], [[rendezvous-600s-cap-too-short-heavy-tasks]], [[reconcile-live-state-implemented-feature-branch]].
## Contexte binaire au moment du plan
- AppImage qui tournait = build **23/06 19:42**, PÉRIMÉ (antérieur à `c6f0f86` encode_cwd, `744de20` backstop no-reply, `886bb0d`/`1efe2f1` reconcile). Décision utilisateur : **rebuild develop HEAD `1efe2f1` puis relance** avant de tester.
- Règle structurelle : **binaire qui tourne = AppImage**. Tout fix backend ⇒ rebuild + relance d'IdeA (tue Main). Les tests s'enchaînent SANS relance *à l'intérieur d'une même version* ; chaque cycle de fix = 1 relance.
## Méthode
- **Main est le demandeur** (`idea_ask_agent`) = test fidèle de « si je donne un message à un agent, il me répond ».
- Doublé d'**observation externe Bash** : ponts `ss -xp | grep idea-mcp` et `pgrep -af mcp-server` ; transcripts `~/.claude/projects/<run-dir-encodé>/*.jsonl` (horodatages **UTC** ; reply réel = `tool_use` idea_reply→tool_result `reply … delivered` ; wedge demandeur = transcript figé sur `tool_use` idea_ask_agent sans tool_result) ; live-state via `idea_workstate_read`.
- Risque résiduel : un wedge non borné fige le tour de Main → l'utilisateur peut interrompre.
## Setup IdeA à mettre en place avant T1 (consigne utilisateur)
1. Relancer IdeA, ouvrir le projet IdeA, **Main visible** (le demandeur).
2. Garder **23 cellules libres visibles** pour qu'on observe à l'œil les délégations (Main y placera des cibles visibles, ou lance-toi QA + DevFrontend dans des cellules visibles).
3. **Laisser Architect, DevBackend, Git ARRÊTÉS (froids)** : T3 testera le réveil à froid ; T9 utilisera Architect+DevBackend froids.
4. Cibles chaudes pour T1/T2 : Main les réchauffe lui-même (launch) — pas d'action requise.
## Ordre des tests (trivial → tordu)
- **T1 — Visibilité outils MCP.** Un agent lancé par IdeA voit ses outils sans action manuelle. Vérif : pont ESTAB (`ss`) + 2 process mcp-server par requester.
- **T2 — Cible CHAUDE + idea_reply trivial.** Main→ask(agent chaud, « réponds pong via idea_reply »). Attendu : réponse inline `pong`, temps borné, workstate working→done purgé.
- **T3 — Réveil à FROID + idea_reply.** Cible arrêtée. Attendu : pont relancé (nouveau mcp-server), **1er tour non perdu** (1er user `[IdeA · tâche…]` intact), reply remonte.
- **T4 — Cible BACKGROUND (node_id None).** Délégation vers agent sans cellule visible. Attendu : même protocole, pas de 1er tour perdu (historiquement non testé).
- **T5 — NO-REPLY (cible répond en prose, pas d'idea_reply).** Attendu backstop : demandeur libéré en temps borné avec `TargetReturnedNoReply` (retryable), **pas de Busy fantôme** (workstate purgé). DÉFAUT historique #1.
- **T6 — Délégation MULTI-ÉTAPES puis idea_reply.** Cible lit plusieurs fichiers / lance une cmd PUIS idea_reply. Attendu : **pas de libération prématurée** pendant le travail, rapport final livré. PIÈGE turn-watcher (cause racine : backstop tirait au 1er tour interne ~3 s).
- **T7 — Tâche LOURDE > plafond** (impl + `cargo test`/clippy). Attendu : extension sur signe de vie OU message clair « cible active, plafond atteint » (≠ faux `-32001`) ; idea_reply tardif non perdu. Plafond `IDEA_ASK_RENDEZVOUS_TIMEOUT_MS` (défaut 600000).
- **T8 — Délégations PARALLÈLES** (2 cibles en 1 tour Main). Attendu : rendez-vous multiples simultanés OK, multiplexage pont, 2 réponses distinctes.
- **T9 — TRANSITIVE A→B→C** (Main→Architect, Architect délègue à DevBackend puis reply à Main). Attendu : rendez-vous imbriqués, 2 attentes simultanées sans deadlock. Cas le plus tordu.
- **T10 — INTERRUPTION/annulation + reconcile reboot.** (a) Main interrompt un ask en vol → `working` cible purgé, pas de cascade, idea_reply tardif non-livrable proprement. (b) Au reboot, orphelins status∈{working,waiting,blocked} & session morte → `idle` + marker `STALE_AT_RESTART_MARKER` (use case ReconcileLiveState, cf. [[reconcile-live-state-implemented-feature-branch]]).
## Critère de fin
Tous les T1→T10 verts avec preuve réelle (réponse inline + observation externe cohérente). Sinon : 1er rouge = blocage à corriger, puis reprise de T1.

View File

@ -1,33 +0,0 @@
---
name: mcp-functional-tests-t1-t9-green-live-2026-06-24
description: memory note mcp-functional-tests-t1-t9-green-live-2026-06-24
metadata:
type: project
---
---
title: MCP tests fonctionnels T1→T9 VERTS en live (2026-06-24, AppImage 12:53 HEAD 1efe2f1 + fix T7 non committé)
type: project
description: Passe complète T1→T9 verte en conditions réelles sur AppImage du 24/06 12:53 ; T5 (backstop no-reply) et T7 (watchdog inactivité >600s) validés live ; reste T10 (interruption + reconcile reboot) qui exige action utilisateur.
---
# Tests fonctionnels MCP rendez-vous — T1→T9 VERTS live (2026-06-24)
Run a6ced819, plan [[mcp-functional-test-plan-2026-06-24]]. AppImage **rebuild 12:53 depuis l'arbre de travail** (HEAD `1efe2f1` + le fix T7 watchdog **non committé** mais présent dans les 11 fichiers modifiés du git status → embarqué dans le binaire). Méthode : Main demandeur + observation externe (ss/pgrep/transcripts UTC/workstate).
## Résultats (preuve réelle)
- **T1 visibilité MCP** ✅ : agents chauds = pont ESTAB + 2 mcp-server (app-tauri parent + AppImage) chacun.
- **T2 cible chaude + reply trivial** ✅ : DevFrontend → `pong` inline, reply delivered 10:56:51 UTC, workstate done (pas de Busy fantôme).
- **T3 réveil à FROID** ✅ : Git froid → `pong-cold` ; nouveau pont spawné, **1er tour `[IdeA·tâche]` intact** (régresseur encode_cwd résolu), reply delivered 10:57:34.
- **T4 cible BACKGROUND (node_id None)** ✅ : Git background → `pong-bg`, reply delivered 10:58:14.
- **T5 NO-REPLY backstop** ✅ (défaut historique #1 résolu) : cible répond en prose sans idea_reply → demandeur libéré en ~20 s avec erreur retryable « returned to its prompt without calling idea_reply », workstate cible done (PAS de Busy fantôme).
- **T6 multi-étapes** ✅ (piège turn-watcher résolu) : DevFrontend lit fichiers + git log PUIS idea_reply ; pas de libération prématurée ; données réelles (142 fichiers, hashes corrects).
- **T7 tâche LOURDE >600s** ✅ (défaut historique #2 résolu, validation live du fix watchdog) : QA charge réelle continue 11:00:46→11:12:44 UTC = **~11m58s**, cargo clean+build release+test (1632 passed/0)+clippy+9 relances ; rendez-vous **NON expiré à 600s**, idea_reply accepté au-delà du plafond (aucun « no pending request »), reply delivered 11:13:21.
- **T8 PARALLÈLE** ✅ : 2 asks même tour (DevFrontend `alpha-8` + Git `beta-8`), réponses distinctes, multiplexage pont OK.
- **T9 TRANSITIF A→B→C** ✅ : Main→Architect→DevBackend (les 2 froids) → `relay:gamma-9:done` ; rendez-vous imbriqués + double réveil à froid sans deadlock ; DevBackend reply delivered 11:14:32.
## Reste : T10 (exige action utilisateur)
- **T10a interruption** : Main interrompt un ask en vol → attendu : workstate cible purgé, pas de cascade, idea_reply tardif proprement non-livrable. NÉCESSITE que l'utilisateur appuie sur interrupt pendant un ask wedgé.
- **T10b reconcile reboot** : orphelin status∈{working,waiting,blocked} + session morte → au reboot, use case ReconcileLiveState le passe à idle + `STALE_AT_RESTART_MARKER` (cf. [[reconcile-live-state-implemented-feature-branch]]). NÉCESSITE un reboot d'IdeA (ferme Main).
## Suite recommandée
1. Faire committer le fix T7 par Git (encore non committé, cf. [[git-owns-commit-merge-decisions]] + [[rendezvous-600s-cap-too-short-heavy-tasks]]).
2. Exécuter T10 avec l'utilisateur (interrupt + reboot).

View File

@ -1,29 +0,0 @@
---
name: mcp-t10a-harness-interrupt-does-not-cancel-rendezvous
description: memory note mcp-t10a-harness-interrupt-does-not-cancel-rendezvous
metadata:
type: project
---
---
title: T10a — l'interrupt harness du demandeur n'annule PAS le rendez-vous backend (reply tardif accepté dans le vide)
type: reference
description: Finding T10a (2026-06-24) — interrompre Main (demandeur) au niveau Claude Code ne propage aucune annulation à IdeA ; la cible finit, son idea_reply est « delivered » dans un demandeur abandonné, et la live-state du demandeur reste working.
---
# Finding T10a (2026-06-24, run a6ced819)
## Setup
Main → `idea_ask_agent(DevFrontend, "travaille ~90s puis idea_reply late-10a")`. Pendant l'attente, l'utilisateur **interrompt Main** (Échap harness Claude Code). Le tool use `idea_ask_agent` est rejeté côté harness.
## Observé
- DevFrontend a fini ses ~95 s de travail réel (11:20:39→11:22:14 UTC) puis `idea_reply("late-10a")`**ACCEPTÉ « delivered »** à 11:22:18 (PAS « no pending request »).
- DevFrontend workstate = **done** (pas d'orphelin côté cible). Pas de cascade.
- **Main (demandeur) workstate resté `working`** : l'interrupt a coupé le tour de Main avant son nettoyage ; le chemin interrupt ne réconcilie pas la live-state du demandeur.
## Interprétation
L'interrupt Claude Code annule le **tool call local** mais le **process Main survit** → la socket MCP (mcp-server du demandeur) reste connectée → IdeA ne reçoit aucun signal d'annulation → le rendez-vous reste pending → le reply tardif de la cible est livré dans un demandeur qui a déjà abandonné (perdu pour Main mais rapporté « delivered »).
## Conséquence
- Le T10a du plan (« annulation en vol → reply tardif non-livrable proprement ») **n'est pas exerçable via interrupt harness** tant que le process demandeur survit. Une vraie annulation exigerait : tuer le process demandeur (drop socket) OU un cancel protocolaire JSON-RPC.
- Comportement néanmoins bénin : pas de wedge, pas de cascade, cible réconciliée (done). Seuls écarts : (a) reply tardif « delivered » au lieu de rejeté ; (b) live-state du demandeur laissée working par le chemin interrupt (mais reconcile-au-reboot la rattraperait, cf. [[reconcile-live-state-implemented-feature-branch]]).
Lié à [[mcp-functional-tests-t1-t9-green-live-2026-06-24]], [[mcp-functional-test-plan-2026-06-24]].

View File

@ -1,24 +0,0 @@
---
name: mcp-t10b-pending-reboot-verification
description: memory note mcp-t10b-pending-reboot-verification
metadata:
type: project
---
---
title: T10b PASS — reconcile au reboot vérifié, inclut l'orchestrateur (2026-06-24)
type: project
description: T10b validé live après reboot. ReconcileLiveState ramène l'orphelin Main working→idle en conservant l'intent et purgeant ticket/lastDelegation. Couvre l'orchestrateur. Reste : faire committer par Git les fix non committés (T7 watchdog + reconcile).
---
# T10b — PASS (reboot reconcile vérifié)
## Verdict
Orphelin armé = Main `working` intent "T10b-ORPHAN-MAIN". Après reboot (run a6ced819), `idea_workstate_read` montre Main :
- `status: idle` ✅ (était working)
- `intent` conservé ✅
- `ticket` purgé ✅ / `lastDelegation` purgé ✅
Signature `STALE_AT_RESTART_MARKER` complète. **ReconcileLiveState valide ET inclut l'orchestrateur** (Main n'a PAS été exclu malgré la crainte du design open_project). Champ `progress` non exposé par workstate_read mais transition working→idle+intent retenu = concluante.
## Suite du plan
T1→T10 du plan [[mcp-functional-test-plan-2026-06-24]] terminés (T1→T9 verts cf. [[mcp-functional-tests-t1-t9-green-live-2026-06-24]], T10a finding [[mcp-t10a-harness-interrupt-does-not-cancel-rendezvous]], T10b PASS ici).
**RESTE : faire committer par Git les fix non committés (T7 backstop/watchdog + reconcile live-state).** cf. [[git-owns-commit-merge-decisions]].

View File

@ -1,37 +0,0 @@
---
name: mcp-t7-backstop-600s-reply-rejected-livestate-stale
description: memory note mcp-t7-backstop-600s-reply-rejected-livestate-stale
metadata:
type: project
---
---
title: MCP T7b/T7e — backstop 600s rejette le reply tardif et laisse le live-state worker non réconcilié
type: reference
description: Finding fonctionnel des tests MCP T7b/T7e (2026-06-24) — un idea_reply après dépassement de la fenêtre 600s est refusé « no pending request », et le ticket du worker reste working dans le live-state.
---
# Finding — tests MCP T7 (2026-06-24, QA)
## Contexte
Série de tests du rendez-vous `idea_ask_agent ⇄ idea_reply` et du backstop no-reply (cap ~600s), demandés par Main :
- **T7d** (debug build x3, avant-plan) : cumul ~3m49s < 600s reply OK.
- **T7b** (9 étapes `sleep 82`, entrelacées) : le harness BLOQUE tout `sleep` avant-plan exécutées en run_in_background ; reply OK (tardif mais < fenêtre côté ticket T7b).
- **T7e** (release build répété, avant-plan, sans sleep ni bg) : 7 cycles, cumul réel **08:01:14 → 08:14:21 = 13 min 07 s**, franchit largement 600s.
## Défaut observé
À la fin de T7e (et de T7b, terminé au même tour, après >600s d'occupation continue), les DEUX `idea_reply` (tickets `4613262f…` T7b et `d2398b22…` T7e) sont refusés :
```
invalid input: no pending request to reply to for agent aefdbd61-…
```
→ Le backstop a libéré le **demandeur** (Main) côté rendez-vous après dépassement du cap, ce qui est le comportement voulu. MAIS :
1. Le **résultat réel** (builds OK, horodatages non falsifiés) ne peut **plus être délivré** : il est perdu pour le demandeur.
2. `idea_workstate_read` montre encore le worker QA `status=working ticket=d2398b22…` **après** le rejet du reply → le live-state du **worker** n'est PAS réconcilié quand le backstop ferme le rendez-vous côté demandeur. Incohérence demandeur (libéré) vs worker (toujours working).
## Conséquence / piste
- Le cap 600s du rendez-vous reste trop court pour des tâches lourdes légitimes (cf. [[rendezvous-600s-cap-too-short-heavy-tasks]]) : ici un travail réel et honnête >13 min est « jeté ».
- À corriger : quand le backstop ferme un rendez-vous, soit (a) accepter encore un reply tardif (le router vers le demandeur même après timeout / le persister), soit (b) réconcilier le live-state du worker (passer son ticket à done/abandon) pour ne pas laisser un `working` fantôme. Voir [[backstop-fires-on-intra-task-turn-rootcause]] et [[rendezvous-no-reply-backstop-design]].
## Reproductible
Charge avant-plan réelle (`cargo build --release --workspace` en boucle clean) dépassant 600s, puis tenter `idea_reply` sur le ticket d'origine → rejet systématique.

View File

@ -0,0 +1,25 @@
---
name: model-catalogue-compat-cadrage
description: Frontières hexagonales, ports, DTO, fallback et matrice de compatibilité versionnée pour l'évolution du catalogue de modèles des profils structurés Codex/Claude.
metadata:
type: reference
---
Évolution de `ListClaudeModels`/`ListCodexModels` (catalogue statique `application/src/agent/model_catalogue.rs`) vers un catalogue enrichi par compatibilité CLI.
**Décisions tranchées :**
- JAMAIS scraper les TUI `/model`, JAMAIS exécuter les CLIs pour énumérer les modèles. Seule exécution CLI autorisée : `<cli> --version` (pattern existant `infrastructure/runtime::detection_spec` + port `ProcessSpawner`). Saisie libre toujours ouverte.
- 3 sources non bloquantes à dégradation indépendante : API provider `/v1/models` (best-effort, uniquement si clé env/SecretStore présente, sinon skip), catalogue statique seed, matrice de compat.
**Hexagonal :**
- Domaine (pur) : VO `CliVersion` (Ord), enum `ModelCompatibility {Compatible|Unknown|LikelyTooRecent}` (miroir des 3 états produit), VO `CompatibilityMatrix` (forme seule), fonction pure `evaluate_compatibility(matrix, adapter, model_id, Option<CliVersion>)` — version None ⇒ Unknown, modèle absent ⇒ Unknown, min<=ver ⇒ Compatible, min>ver ⇒ LikelyTooRecent.
- Nouveaux ports : `CliVersionReader`, `ProviderModelCatalogue` (Ok(vec![]) si pas de clé), `CompatibilityMatrixSource` (infaillible).
- Application : use case unique `ResolveModelCatalogue{adapter}` async, jamais de hard-error sur échec source (warnings + fallback). `ListClaude/CodexModels` deviennent des façades.
- Infra : `ProcessCliVersionReader`, `HttpProviderModelCatalogue` (reqwest), `EmbeddedCompatibilityMatrix`.
**Matrice de compat = DONNÉE, pas code** : JSON versionné maintenu dans IdeA, bundlé via `include_str!` (seed infaillible) + override optionnel `app_data_dir/IdeA/model-compat.json`. Ajouter un modèle = éditer le JSON, zéro code (Open/Closed).
**DTO (rupture front)** : `ProfileModelCatalogDto` passe de `transparent Vec` à `{ models:[{...,compatibility,source}], cliVersion:string|null, warnings:string[] }`. Répercuter ports TS + 2 adapters + mock + ProfilesSettings.
**Découpage** : B1 domaine pur, B2 use case ports mockés, B3 infra ; F1 contrat, F2 ProfilesSettings 3 badges. UX passe avant F2 (libellés des 3 états, warnings, cliVersion null).
**Point ouvert produit** : récup clé provider — proposé best-effort sur clé env/SecretStore existante, pas de prompt dédié.

View File

@ -0,0 +1,50 @@
---
name: multi-profile-codex-claude-model-catalogue-scoping
description: memory note multi-profile-codex-claude-model-catalogue-scoping
metadata:
type: project
---
# Cadrage : profils multiples Codex/Claude + catalogue de modèles
Demande utilisateur : plusieurs profils Codex et Claude, chacun avec son modèle, assignables aux
agents ; lister les modèles plutôt que saisie manuelle quand possible.
## État vérifié de l'existant (2026-07-26)
Le backend est déjà générique multi-profils, contrairement à ce qu'on pourrait croire à la lecture
seule des mémoires F35/F36 (qui documentaient le cas OpenCode) :
- `AgentProfile` (crates/domain/src/profile.rs) porte déjà `model: Option<String>` (ticket #99,
explicitement prévu pour Codex/Claude), et `profiles.json` (FsProfileStore) est une **liste**
indexée par `id`, pas un slot singleton par provider.
- Commandes déjà câblées : `list_profiles`, `save_profile` (upsert générique par id),
`delete_profile`, `reference_profiles`, `detect_profiles`.
- Ce qui existe **seulement pour OpenCode** : `clone_opencode_profile_from_seed` (alloue un id
frais via IdGenerator) et `save_opencode_provider_profile`, plus un vrai catalogue de modèles
(`crates/application/src/agent/provider_catalogue.rs`, lit le cache models.dev d'OpenCode avec
repli statique).
- `catalogue.rs` : un seul profil de référence Claude et un seul Codex, aucun `.with_model(...)`.
- Frontend `ProfilesSettings.tsx` : simple list+delete, pas de create/duplicate/edit inline ;
toute édition rouvre `FirstRunWizard`.
## Gaps identifiés (pas de migration de schéma nécessaire)
1. Backend : généraliser le pattern `CloneOpenCodeProfileFromSeed` (fresh_profile_id via
IdGenerator) en un use case `CloneProfileFromSeed` non spécifique à OpenCode, pour dupliquer un
profil Claude/Codex avec un nom + `model` en override. Ne PAS laisser le frontend miner l'id
(romprait la discipline IdGenerator déjà en place).
2. Backend : catalogue de modèles Claude/Codex — aucune API fiable côté CLI, donc liste statique
curée (même esprit que `static_fallback_catalogue()` d'OpenCode), exposée par commande Tauri
infaillible (`list_claude_models`/`list_codex_models` ou générique par `structuredAdapter`).
Le frontend garde toujours un champ de saisie manuelle en repli (liste jamais garantie
exhaustive).
3. Frontend : refonte `ProfilesSettings.tsx` en onglets Codex/Claude/OpenCode avec
create/duplicate/edit/delete par onglet + `ModelSelect` searchable partagé ; simplifier
`FirstRunWizard` pour ne créer qu'un profil par défaut par provider détecté, avec renvoi vers
Settings pour en ajouter d'autres.
## Découpage de livraison
DevBackend (use case + catalogues + commandes, petit lot, zéro migration) → DevFrontend (refonte
Settings + first-run simplifié) → QA (créer 2 profils Claude modèles différents + 2 Codex, assigner
à des agents distincts, vérifier le bon modèle atteint la CLI au lancement, non-régression
OpenCode) → Git (branche feature unique, lot petit et couplé).

View File

@ -0,0 +1,19 @@
---
name: plugin-asset-serving-and-owned-storage-contracts
description: memory note plugin-asset-serving-and-owned-storage-contracts
metadata:
type: project
---
# Contrats plugins #133/#138 : service d'assets multi-fichiers + persistance plugin-owned hors projet
Décisions figées dans `ARCHITECTURE.md` §22 (2026-08-02).
## #133 — service des assets `idea-plugin://`
`asset_allowed` (`crates/app-tauri/src/plugins.rs:504-536`) doit servir tout chemin relatif confiné dès lors que les gardes déjà présentes tiennent : registre actif (`lifecycle_state.is_runtime_active()`) + `content_hash` du package matché + confinement canonicalize (déjà en place lignes 467-483). Fin de l'allowlist `declared_main || declared_icon || starts_with("assets/")` qui cassait tout import ESM relatif secondaire (`./constants.js`, `./core/x.js`) → "Importing a module script failed.". Pas de résolution `node_modules`/bare specifiers — hors scope, figé. Débloque #134 (implémentation) et #135 (audit confinement install + désinstallation 100%).
## #138 — persistance plugin-owned
`ctx.storage` (déjà typé dans `sdk/IdeaSDK/src/runtime.ts`, jamais câblé côté `frontend/src/plugins/runtime/loader.ts` ni implémenté côté Rust — vérifié : zéro port/commande/répertoire) devient l'API canonique unique pour l'état interne du plugin (prefs/cache/index). Nouveau répertoire `app_data/plugins/data/<pluginId>/`, frère de `plugins/installed/<pluginId>/` (jamais dedans, pour survivre aux réinstalls et donner une racine univoque à purger). `plugin_uninstall` doit purger les deux répertoires. `ctx.services.config`/`workspace` restent réservés au project-owned (fichiers réels du projet, jamais l'état interne du plugin). L'exemple `hello-plugin` doit migrer ses compteurs internes de `.ideai/hello-plugin.json` vers `ctx.storage`. Débloque #139.
Détail complet et rationale : `ARCHITECTURE.md` §22. Tickets liés : #133/#134/#135 (assets), #138/#139 (storage). Les deux tickets #133/#138 sont passés en `QA` avec carnet détaillé.

View File

@ -1,25 +0,0 @@
---
name: reconcile-live-state-implemented-feature-branch
description: memory note reconcile-live-state-implemented-feature-branch
metadata:
type: project
---
---
title: Réconciliation du live-state au reboot — implémentée (feature/reconcile-live-state)
type: project
description: Le chantier ReconcileLiveState (3 lots) est implémenté et vert (1623 tests), non committé ; détail des fichiers et de l'arbitrage project_id/provider.
---
Implémenté le 2026-06-23 sur `feature/reconcile-live-state` (ticket Main a7fcb5e4, dont le rendez-vous `idea_reply` a expiré pendant le build — résultat consigné ici). **Non committé** (Git tranche). Cadrage : [[live-state-reboot-reconciliation-design]].
**Résultats réels** : `cargo test --workspace` = **1623 passed, 0 failed**. `cargo clippy --workspace --all-targets` = 0 erreur, aucun warning sur le code ajouté (warnings restants tous pré-existants).
**Lot 1 (domaine, `crates/domain/src/live_state.rs`)** : `LiveState::reconcile_orphans(is_live, now_ms) -> Vec<LiveEntry>` pure (ne mute pas self). Orphelin = status ∈ {Working,Waiting,Blocked} ET !is_live → réécrit status=Idle, intent gardé, ticket=None, last_delegation=None, progress=Some(`STALE_AT_RESTART_MARKER`), updated_at_ms=now. Const pub `STALE_AT_RESTART_MARKER = "(stale — session not running at restart)"`. +4 tests.
**Lot 2 (application, nouveau `crates/application/src/workstate/reconcile.rs`)** : use case `ReconcileLiveState` sur `LiveStateStore`+`LiveAgentRegistry`(ISP)+`Clock` ; `execute(ReconcileLiveStateInput{project_id})` charge → reconcile_orphans → upsert par ligne. +3 tests. Exporté via workstate/mod.rs + application/lib.rs.
**Lot 3 (app-tauri, `state.rs`+`commands.rs`)** : provider par-root `AppReconcileLiveState` (résout root via `ProjectStore::load_project`, `FsLiveStateStore::new(&root)`, registre = `LiveSessions` existant). Champ `reconcile_live_state` sur AppState. Hook best-effort dans `open_project` après `reconcile_layouts`. **Acte système** : écrit le port `LiveStateStore` directement, jamais via `OrchestratorCommand::SetWorkState` → self-only de `idea_workstate_set` préservé par construction.
**Arbitrage à valider QA/Architect** : la résolution project_id→root se fait au composition root (le store est root-bound), donc `ReconcileLiveState::execute` reçoit bien `ReconcileLiveStateInput{project_id}` (conforme Lot 2 + hook Lot 3 à la lettre) mais ne relit pas project_id dans le flux pur (`_input`). Variante sans ce param redondant = ajustement trivial si souhaité.
**Fichiers (6)** : domain/src/live_state.rs ; application/src/workstate/reconcile.rs (nouveau) ; application/src/workstate/mod.rs ; application/src/lib.rs ; app-tauri/src/state.rs ; app-tauri/src/commands.rs.

View File

@ -1,39 +0,0 @@
---
name: resume-after-appimage-rebuild-mcp-e2e
description: memory note resume-after-appimage-rebuild-mcp-e2e
metadata:
type: project
---
---
name: resume-after-appimage-rebuild-mcp-e2e
description: Point de reprise — programme live-state CLOS+RELEASÉ (0.3.0), discordance .gitignore D19-4 TRANCHÉE. Prochain chantier = validation MCP e2e UX. Chantiers restants priorisés.
metadata:
type: project
---
# Reprise — état au 2026-06-22 (run a6ced819)
## Où on en est
- **Programme live-state / persistance CLOS et RELEASÉ** : `develop` @ `36be0cb` (LS8), `main` @ `29232dd` = `release(0.3.0): intègre develop dans main`. Détail : [[live-state-persistence-program-closed-ls8]]. Doc : `docs/LS8-live-state-persistence-closure.md` + `ARCHITECTURE.md` §21.
- **AppImage rebuildée + tournante** : `IdeA_0.3.0_amd64.AppImage` (le nom n'est plus 0.1.0). Le binaire live embarque tout le programme ; 6 ponts MCP connectés/ESTAB observés → point 1 du chantier e2e (agent voit ses outils MCP sans action manuelle) déjà satisfait en réel. Recette rebuild (rappel) : `npm --prefix frontend run build` puis depuis `crates/app-tauri/` `APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 ../../frontend/node_modules/.bin/tauri build --bundles appimage` ; remplacer l'AppImage installée → relancer.
- **Discordance .gitignore ↔ D19-4 : TRANCHÉE** (par l'utilisateur) et exécutée par Git → commit `47b3806` sur `develop` (`chore(gitignore): désuivre .ideai/conversations/`). Périmètre réel : seul `.ideai/conversations/` était discordant (16 fichiers suivis, 8 handoff.md + 8 log.jsonl) ; `.ideai/run/` et `.ideai/live-state.json` étaient déjà ignorés/propres. Désuivis (rm --cached, conservés sur disque) + règle ajoutée `.gitignore:58`. Plus une décision en attente.
## Prochain chantier (priorité 1) : VALIDATION MCP END-TO-END UX
Objectif = valider/durcir en situation RÉELLE le parcours inter-agents (le code est probablement bon, Bugs 1→7 corrigés cf. [[mcp-bridge-and-delegation-runtime-notes]], mais ces bugs ne sont apparus qu'en live). À vérifier sur l'AppImage 0.3.0 :
1. Un agent lancé par IdeA voit ses outils MCP sans action manuelle. (déjà OK observé)
2. Délégation vers agent FROID et vers agent BACKGROUND (node_id None) : tâche bien écrite dans le PTY, pas de 1er tour perdu, pas de `Busy` fantôme après interruption/annulation (Bugs 3/4/6/7).
3. Un `ask` sans réponse ne wedge pas la connexion du demandeur (Bug 5).
4. Profils Claude/Codex utilisent MCP par défaut ; fallback fichier+prose cohérent sinon.
5. Observabilité UI des délégations/replies (aujourd'hui opaque) — sujet UX.
**CONTRAINTE MÉTHODO** : NE PAS réparer/valider le système inter-agents VIA le système inter-agents (`idea_ask_agent`). Piloter via les **subagents natifs (outil Agent)**, et demander à l'utilisateur de faire tourner l'AppImage + observer (Main ne peut pas valider seul depuis l'intérieur). Diag live : `ss -xp | grep idea-mcp` (ponts connectés) ; `~/.claude/projects/<encoded-run-dir>/*.jsonl` (transcript ; pas de nouveau fichier = tâche jamais soumise).
## Autres chantiers restants (depuis [[remaining-work-idea-agent-control-ide]])
- **Auto-update mémoire/contexte EN COURS de session** (aujourd'hui injection au lancement seulement) — priorité 1.
- **Multi-fenêtres / déplacement d'onglet** du registre de sessions — priorité 2 (UI).
- Optionnels différés : activation réelle du seam LLM de handoff (contrat figé ADR LS5, défaut heuristique) ; sweep périodique de rotation (idempotent, non câblé).
## Friction outillage notée (par Git, sans incidence résultat)
Le `settings.local.json` du run dir a un `deny` qui bloque Edit/Write et certaines redirections Bash pour les agents en run dir isolé ; Git a dû éditer `.gitignore` via `tee -a`. À assouplir si on veut des éditions de fichiers propres côté run dir.
## Contrainte d'écriture (rappel)
Main + agents en run-dir isolé ne peuvent PAS écrire l'arbre du project root (docs/, ARCHITECTURE.md, .ideai/memory/*.md fichiers) — permissions déniées. Mémoire IdeA : outil `idea_memory_write` (create/replace par slug ; pas de delete). Suppression fichiers mémoire / édition MEMORY.md / CLAUDE.md / .gitignore du project root : passer par **Git**.

View File

@ -0,0 +1,42 @@
---
name: sandbox-eperm-bind-false-green-web-server
description: memory note sandbox-eperm-bind-false-green-web-server
metadata:
type: project
---
---
name: sandbox-eperm-bind-false-green-web-server
description: Les sandboxes de DevBackend et QA bloquent TcpListener::bind (EPERM) ; tout `cargo test` sur web-server/app-tauri y rend un VERT QUI NE PROUVE RIEN. Vérifier hors sandbox.
metadata:
type: reference
---
# Faux vert : `TcpListener::bind` interdit dans les sandboxes agents
## Le fait
Les environnements d'exécution de **DevBackend et de QA** refusent `TcpListener::bind("127.0.0.1:0")` avec `Operation not permitted (os error 1)`. Tout test qui ouvre un socket y est structurellement inexécutable.
Crates concernés : `web-server`, `app-tauri` (pont MCP, serveur embarqué).
## Pourquoi c'est dangereux, pas juste gênant
Le 2026-07-16, ce piège s'est refermé **deux fois dans la même journée** :
1. **#68 B1** — DevBackend annonce « 57 passed ». En réalité le test `run_embedded_stop_shuts_down_accept_loop` sortait en silence sur EPERM via un repli, et le test du core partagé basculait sur un dispatch in-process. Rejoué **hors sandbox** : échec réel, révélant un **vrai bug produit**`run_embedded` ne réconciliait pas le port effectif avec la config, donc `origin_allowed` comparait l'origine à `http://127.0.0.1:0` et un serveur embarqué sur port éphémère **rejetait toutes les requêtes API en 403**. Le trou n'avait jamais été vu parce que rien ne consommait `run_embedded`.
2. **#72** — même schéma, cette fois signalé honnêtement par DevBackend (« 63 passed; 2 failed » sur EPERM) après consigne explicite.
Un repli silencieux sur EPERM transforme un test en décoration : il passe sans rien exercer, et masque la classe de bug qu'il était censé attraper.
## La règle
- **Aucun repli EPERM silencieux.** Un test qui ne peut pas s'exécuter doit **échouer visiblement** ou être `#[ignore]` explicite avec sa raison — jamais « passer ».
- **Tout vert sur `web-server`/`app-tauri` doit être produit hors sandbox** (`dangerouslyDisableSandbox: true` côté Main, qui n'a pas la restriction). Ne jamais accepter un vert sandboxé comme preuve sur ces crates.
- DevBackend et QA doivent **dire ce qu'ils ont pu exécuter et ce qu'ils n'ont pas pu**, plutôt que de rendre un chiffre global.
- Les `#[ignore = "requires local socket bind permission"]` légitimes (ex. `mcp_bridge::tests::end_to_end_over_real_loopback`) se vérifient en les **lançant** hors sandbox avec `--ignored`, pas en raisonnant dessus.
## Principe général
Ne pas confondre « les tests sont verts » et « le code marche ». Le vert d'un environnement contraint ne dit rien du produit. Cette leçon vaut au-delà du bind : un environnement qui ne peut pas exercer un chemin ne peut pas le valider.
Lien : [[appimage-build-no-strip-relr-dyn-fix]] (autre piège d'environnement de cette machine),
[[rendezvous-600s-cap-too-short-heavy-tasks]].

View File

@ -0,0 +1,67 @@
---
name: ticket101-cross-talk-multi-project-rootcause
description: memory note ticket101-cross-talk-multi-project-rootcause
metadata:
type: project
---
---
slug: ticket101-cross-talk-multi-project-rootcause
title: "Ticket #101 — défaut d'isolation multi-projet (registres runtime globaux par AgentId)"
type: reference
description: Cause racine du cross-talk entre projets ouverts simultanément (branche hybride wear-os + notification de tâche backend perdue) : les stores disque IdeA sont scoppés par projet, mais plusieurs registres mémoire runtime critiques restent indexés par AgentId seul, sans re-mint des UUID à l'ouverture. Plan de correction figé en 6 lots (clé RuntimeAgentKey).
---
# Ticket #101 — défaut d'isolation multi-projet (cause racine)
## Symptômes (2 manifestations, même défaut)
- **A — contamination du contexte d'inférence** : un agent a créé une pseudo-branche `feature/ticket91-wear-os-watch-sync` (ticket #91 purement front) où le suffixe `wear-os-watch-sync` appartient à l'AUTRE projet de l'utilisateur. Le nom n'apparaît dans aucun fichier `.ideai/` du projet IdeA → contamination au niveau du contexte d'inférence runtime (conversation injectée à l'agent Git mélangeait les projets). Preuve topo préservée : `main` divergé de `develop` (da907b8 vs 6a87c46), `feature/ticket99-agent-model-configuration` créée depuis main au lieu de develop.
- **B — notification de tâche backend perdue / agent qui s'arrête** (sujet original #101) : un agent OpenCode lance `idea_run_in_background` puis s'arrête, sans retour de notification garanti.
## Cause racine (Architect, 2026-07-25)
Stores disque **correctement scoppés par projet** (mémoire, contexte, handoff, live-state lus depuis `input.project.root` ; agents persistés dans `.ideai/agents.json` par root projet). MAIS les agents **ne re-mint pas leurs UUID à l'ouverture** → deux projets (surtout si l'un est une copie) peuvent porter les **mêmes `AgentId`**.
Plusieurs **registres mémoire runtime restent globaux, indexés par `AgentId` seul** :
- ConversationRegistry global + `ConversationId` dérivé des UUID agents seuls — `crates/domain/src/conversation.rs:71`, `crates/infrastructure/src/conversation/mod.rs:41`, orchestrateur `crates/application/src/orchestrator/service.rs:2192`.
- Sessions PTY/structured retrouvées par `agent_id` seul — `crates/application/src/terminal/registry.rs:182,437` ; réutilisation session `service.rs:2293,2368`.
- Verrous ask, busy-state, liveness, délégations différées par `AgentId` seul — `service.rs:418`, `crates/infrastructure/src/input/mod.rs:47`.
- Inbox/mailbox par `AgentId` seul — `crates/domain/src/inbox.rs:68,156`, `input/mod.rs:1052`, `crates/infrastructure/src/mailbox/mod.rs:44`.
- Wake par `AgentId` seul — `crates/application/src/orchestrator/wake.rs:87`, provider `crates/backend/src/lib.rs:687`.
→ Un agent du projet courant peut se rattacher à la conversation/session/inbox d'un autre projet (collision d'UUID) : contamination d'inférence (A) ET complétion livrable/bloquée/réveillant la mauvaise session (B).
## Pour B : runtime vs modèle
La chaîne sink→`project_id`→wake est correcte jusqu'au bridge (`crates/infrastructure/src/background_task/sink.rs:23,142` ; `crates/backend/src/lib.rs:2228` recharge le projet par `project_id` puis `wake_agent`). Le défaut réapparaît juste après (inbox/mailbox/busy/session par AgentId seul). **Runtime IdeA suspecté en premier.** Le modèle GLM 5.2 n'est l'hypothèse principale que si les logs prouvent (pour le bon `project_id`) : enqueue + wake + `BackgroundTaskCompletionDelivered` émis sans reprise utile. Traces : `lib.rs:2238`, `wake.rs:93`.
## Plan de correction (6 lots, figé)
1. Introduire `RuntimeAgentKey { project_id, agent_id }` ; interdire toute map app-wide indexée par `AgentId` seul.
2. Propager la clé dans `AgentInbox`, `InputMediator`, `AgentMailbox`, busy/liveness/deferred, wake, session lookup, ask-locks. **Correctif structurel commun à A et B.**
3. Qualifier les conversations par projet : `ConversationId` + `ConversationRegistry` intègrent `ProjectId`.
4. Requalifier `TerminalSessions`/`StructuredSessions` par `(project_id, agent_id)` ; `AppWakeSessionProvider` refuse toute session vivante d'un autre projet.
5. Audit des autres états mémoire similaires (`session_limit`, tables de reprise/verrous par agent) pour éviter une demi-correction.
6. Télémétrie `project_id` explicite sur les logs diag critiques de wake/routage.
## Invariants
- Sources de contexte sur disque restent root-scopées (ne pas régresser).
- Templates/profils globaux restent globaux produit — ne doivent pas devenir vecteurs de session/conversation partagée.
- Un projet non-actif doit continuer à recevoir ses wakes et complétions.
- Pas de régression OpenCode/Codex/Claude (correctif transverse runtime, pas moteur-spécifique).
- Aucun nouveau DTO frontend pour la correction minimale.
## QA — critère de vérité
Test d'intégration **non-cross-talk** : 2 projets ouverts simultanément contenant **volontairement les mêmes `AgentId`** :
- délégation dans projet A ne réutilise jamais une session/conversation vivante de projet B ;
- complétion `(project A, agent X)` n'entre ni dans l'inbox ni dans la session de `(project B, agent X)` ;
- le wake d'un projet non-actif fonctionne quand même ;
- une collision d'ids qui échouait avant devient verte sur PTY, structured et background wake.
## Hors périmètre
- #91 (popup de notification) : purement front, indépendant du défaut runtime.
- Remint systématique des AgentId à l'ouverture : piste complémentaire non retenue dans le fix minimal (la clé runtime scellée par projet rend la collision inoffensive même sans remint).
## Topologie
- Branche de travail à créer pour le fix (Git décidera). Base `develop` (6a87c46). `main`/`feature/ticket99-agent-model-configuration` divergent sur da907b8 (preuves préservées, à nettoyer après enquête).
## Lié
- #91 (relatesTo) : popup de notification — front pur.
- Mémoire `background-tasks-first-class-design` + `b8-command-runner-pty-framing` : design du flux de complétion (le défaut est en aval du sink).
- Mémoire `mcp-bridge-and-delegation-runtime-notes` : règle rebuild AppImage (le binaire qui tourne = AppImage, pas les sources).

View File

@ -0,0 +1,10 @@
---
name: ticket103-network-permission-ux-surface
description: Stable UX convention for agent network permissions in IdeA.
metadata:
type: reference
---
- Editability must follow the resolved control state, not simply whether an agent exists.
- Non-launched agents stay editable unless a runtime lock is explicitly present.
- Read-only messaging should be explicit only for active locked runtimes, especially external/uninspectable runtimes.
- Effective policy labels must not be used as a proxy for editability.

View File

@ -0,0 +1,20 @@
---
name: ticket113-controlled-args-field-rootcause
description: memory note ticket113-controlled-args-field-rootcause
metadata:
type: project
---
---
name: ticket113-controlled-args-field-rootcause
description: Cause racine identifiée du bug ticket #113 (espaces impossibles dans le champ Arguments supplémentaires llamacpp) et niveau de fix attendu.
metadata:
type: project
---
Root cause confirmée dans le code (2026-07-31) : `frontend/src/features/model-servers/ModelServersPanel.tsx:645-647` affiche `value={draft.args.join(" ")}` et parse via `parseArgs` (`modelServer.ts:133`, `split(/\s+/).filter(non-vide)`) à chaque `onChange`. Le state du champ est un `string[]` reconstruit en texte à chaque frappe, donc tout espace en fin de saisie ou espace double est immédiatement absorbé avant le prochain re-render : l'utilisateur ne peut jamais laisser un espace « en attente ».
Le même pattern existe à l'identique dans `frontend/src/features/first-run/FirstRunWizard.tsx:264` (même `parseArgs` importé depuis `first-run/profile.ts`) — probablement le même bug latent, non signalé par l'utilisateur mais à couvrir dans le même correctif.
**Why:** classique piège de champ contrôlé dont le state est un type dérivé (array) plutôt que la chaîne brute tapée — le round-trip parse→join efface la saisie en cours.
**How to apply:** le fix attendu est purement frontend/local : garder une valeur de saisie brute en state local (string) pendant la frappe, ne convertir vers `args: string[]` qu'à la sortie du champ (blur/submit), sans reconstruire `value` depuis `args.join(" ")` à chaque `onChange`. Aucun changement domaine/backend/DTO nécessaire — `args: string[]` reste le contrat de sortie inchangé.

View File

@ -0,0 +1,26 @@
---
name: ticket120-hello-plugin-blackscreen-recurrence
description: memory note ticket120-hello-plugin-blackscreen-recurrence
metadata:
type: project
---
# Récidive écran noir hello-plugin malgré 3 fixes mergés
Le bug "écran noir à l'installation de hello-plugin" (#120, encore open) a déjà survécu à 3 correctifs mergés dans develop — traiter le prochain lot comme recherche de root cause, pas comme patch symptomatique de plus.
## Constat
Le ticket #120 ("Réinvestiguer l'installation de hello-plugin: écran noir / perte d'affichage IdeA") est toujours **`open`** au 2026-08-01, alors que **trois** correctifs distincts ont déjà été mergés dans `develop` sur le même symptôme :
1. `fix/ticket116-plugin-install-black-screen` → mergé `f6685aa` (ticket #116, closed) — "isoler crash plugin hello-plugin + erreur explicite UI"
2. `feature/hello-plugin-manifest-fix-and-fixture-tests` → mergé `6270f98` — "aligne le manifeste hello-plugin sur le schéma backend + fixture de test"
3. `feature/ticket120-hello-plugin-blackscreen-reinvestigation` → mergé `e741f76` (aujourd'hui) — "isolation plugin invalide + réconciliation MCP durcie + loader export default/cleanup"
Et le bug revient une 4e fois, ce qui a motivé la relance de #120 le 2026-08-01 sur la branche `feature/ticket120-hello-plugin-blackscreen-crash-diagnostics`.
**Why** : chaque fix précédent a visiblement traité un symptôme observable (crash isolation, manifeste, réconciliation MCP, loader export) sans que la cause racine soit couverte — sinon le bug ne reviendrait pas. Fermer #120 à chaque merge sans validation e2e réelle post-merge semble être le trou du cycle.
**How to apply** :
- Avant tout nouveau fix sur ce symptôme, lire l'historique des 3 tentatives ci-dessus pour ne pas répéter une piste déjà explorée et retombée.
- Ne pas fermer #120 au merge — seulement après validation réelle de l'installation du plugin de bout en bout (voir [[git-owns-commit-merge-decisions]] pour la règle générale de non-merge sans tests verts, qui s'applique ici avec une vigilance renforcée).
- La dette de diagnostic crash/logs est traitée dans le même lot que ce 4e essai (branche `feature/ticket120-hello-plugin-blackscreen-crash-diagnostics`), précisément pour éviter un 5e patch aveugle.

View File

@ -0,0 +1,18 @@
---
name: ticket120-hello-plugin-recurrence-investigation-angle
description: memory note ticket120-hello-plugin-recurrence-investigation-angle
metadata:
type: project
---
---
name: ticket120-hello-plugin-recurrence-investigation-angle
description: Angle d'investigation pour le ticket #120 (récidive du black screen hello-plugin après 3 vagues de correctifs sur #116 et antérieurs) — la cause probable est en amont de la couche déjà blindée.
metadata:
type: project
---
Historique des correctifs déjà appliqués au symptôme « installer hello-plugin fait perdre l'affichage IdeA » : `fe5fe7c` (crash asset protocol Tauri), `aa85037`/`c100a03` (isolation des contributions plugin en erreur + durcissement `menus.ts`), `d4e61a8`/`f6685aa` (ticket #116, fermé). Constat utilisateur live au 2026-07-31 (ticket #120) : le black screen est **toujours observé** malgré ces trois vagues.
**Why:** trois correctifs successifs ciblant tous la couche « rendu des contributions plugin déjà chargées » sans faire disparaître le symptôme est un signal fort que la cause racine réelle est ailleurs — probablement en amont (flux d'installation backend : validation manifeste, copie assets, écriture manifeste projet — un panic/erreur non catché ici peut tuer le process Tauri entier, ce qu'aucune isolation frontend ne peut rattraper) ou dans le remount/reload post-install côté frontend, pas dans le rendu des contributions lui-même qui a déjà été isolé trois fois.
**How to apply:** pour #120, prioriser l'audit du chemin d'installation backend et de la frontière install→reload frontend AVANT de retoucher l'isolation des contributions (déjà traitée). Reproduire dans l'AppImage réellement rebuild (pas `pnpm dev`), pas seulement en dev — voir [[mcp-bridge-and-delegation-runtime-notes]] sur le piège du binaire qui tourne. Ne pas re-fermer le ticket sans preuve live post-fix dans le binaire réel, comme #116 l'a probablement fait à tort.

View File

@ -0,0 +1,23 @@
---
name: ticket13-f0-frontend-transport-inventory
description: Résultat de l'inventaire B0/F0 frontend du chantier client/serveur #13 — la frontière gateways transport-neutres existe déjà, F1 = ajout d'adapters HTTP+WS.
metadata:
type: reference
---
Inventaire B0/F0 (ticket #13 server/client mode), côté frontend TS/React. Doc : `docs/ticket13-f0-frontend-transport-inventory.md`.
**Constat clé** : la frontière « gateways TS transport-neutres » du plan est DÉJÀ réalisée et testée.
- `src/ports/index.ts` = 21 gateways sans Tauri ; toute la couche `features/`+`app/` en dépend via DI (`useGateways()`).
- `src/adapters/*` = seul lieu important `@tauri-apps/api`.
- Garde L1 `src/app/no-direct-invoke.test.ts` casse la CI si un fichier hors `adapters` importe Tauri / appelle `invoke(`.
- `src/app/di.tsx` `resolveGateways()` bifurque déjà Tauri vs mock → F1 = ajouter `createHttpWsGateways()` (3ᵉ impl).
**Donc F1 = écrire un 2ᵉ jeu d'adapters derrière des ports inchangés, aucun composant métier à réécrire.**
**Flux Channel (→ WebSocket)** : (1) `terminal.ts` PTY, (2) `agent.ts` PTY agent (réutilise `makeTerminalHandle`), (3) `ticket.ts` `sendTicketChat` `Channel<ReplyChunk>`. Tous modélisés côté port par callback `onData`/`onChunk`. Le contrat PTY WS du carnet mappe 1-pour-1 sur `TerminalHandle` (write/resize/detach/close, detach≠close, scrollback au reattach) → port inchangé pour F3. `TerminalView.tsx` ne connaît que le port.
**Event portable** : `system.onDomainEvent("domain://event")` (bus domaine) → WS serveur→client.
**Desktop-only à cadrer** : `system.pickFolder` (dossier = machine serveur ≠ client web → file-picker serveur), `window.ts` (WebviewWindow OS) et `focusedProject.ts` (multi-fenêtres OS) probablement hors V1 web. `uiPreferences` (localStorage) marche tel quel.
Convention DTO à préserver côté adapter HTTP : commandes snake_case, payloads camelCase souvent enveloppés `{ request: {...} }`.

View File

@ -0,0 +1,17 @@
---
name: ticket13-f1-http-ws-adapter-delivered
description: Le 3e jeu d'adapters frontend (HTTP request/response + squelette WebSocket) du chantier client/serveur #13 est livré et vert, derrière les ports inchangés.
metadata:
type: reference
---
Ticket #13 lot F1 livré sur feature/ticket13-server-client-mode. Nouveau dossier `frontend/src/adapters/http/` = 3e implémentation des gateways, à côté de Tauri (desktop) et mock.
**Fichiers** : `httpInvoker.ts` (POST /api/invoke {command,args}, ErrorDto→GatewayError, fetch injectable), `frames.ts` (contrat frames WS B0 + base64), `wsLiveClient.ts` (squelette WS multiplexé : corrélation id↔replyTo, routage terminal.output par session, dispatch event.domain), `requestResponseGateways.ts` (13 gateways R/R, commandes/enveloppes IDENTIQUES aux adapters Tauri), `streamGateways.ts` (HttpSystem/Agent/Ticket/Terminal + makeWsTerminalHandle detach≠close), `unsupported.ts` (Web{Window,FocusedProject,Remote}Gateway, code UNSUPPORTED_ON_WEB), `index.ts` (createHttpWsGateways(config?), endpoints via window.location). Tests : httpInvoker.test.ts, wsLiveClient.test.ts.
**Seam DI** : `app/di.tsx``resolveTransport()` 3-way (mock > http > tauri), web sélectionné par `VITE_TRANSPORT="http"`. Tauri reste défaut (desktop inchangé).
**Décision de contrat clé (à confirmer DevBackend)** : transport RPC générique `POST /api/invoke {command,args}` choisi PLUTÔT que l'arbre REST du brouillon B0 — préserve 1:1 tous les DTO Tauri, zéro divergence, bascule REST future ne touche que httpInvoker.ts. Autres points à trancher : placement token WS (pas en URL ; navigateur ne peut pas fixer d'en-tête upgrade), forme réponse terminal.open/agent.launch (ack terminal.attached avec session.sessionId), projectId absent du port openTerminal.
**Reporté F3/B5/B6** (TODO(F3/B5)) : round-trip xterm réel, reconnexion/backpressure, replay seq/gap, sink chat par-session pour sendTicketChat, agents structurés. Pas de serveur avant B3/B4.
État : build vert (tsc+vite), garde no-direct-invoke verte, 77 fichiers/724 tests verts. Voir [[ticket13-f0-frontend-transport-inventory]].

View File

@ -0,0 +1,19 @@
---
name: ticket13-f2-web-readonly-client-delivered
description: Le client web read-only (pairing cookie, liste projets, ouverture read-only + snapshot work-state) du chantier client/serveur #13 est livré et vert.
metadata:
type: reference
---
Ticket #13 lot F2 livré sur feature/ticket13-server-client-mode. Clôture frontend du premier incrément livrable (B0→B4/F2).
**Nouveau** : `adapters/http/webSession.ts` (WebSession : flag localStorage « paired » — PAS le cookie HttpOnly ; `pair(code)`→POST /api/pair ; `notifyUnauthorized()` clear+notify ; singleton `getWebSession()`), `features/web/` (PairingScreen, WebWorkspace read-only, WebApp gate). Tests : webSession.test.ts, WebApp.test.tsx.
**Modifié** : httpInvoker (credentials same-origin + callback onUnauthorized sur 401), http/index.ts (câble onUnauthorized→webSession), app/main.tsx (monte <WebApp/> si resolveTransport()==="http", desktop inchangé).
**Flux** : non-paired→PairingScreen ; pair OK (cookie HttpOnly posé serveur)→WebWorkspace ; 401 d'un /api/invoke→retour pairing ; « se déconnecter »=clear flag local (révocation serveur=B8). Cookie jamais lisible en JS (HttpOnly) : on se fie au 200 + flag de routage.
**Read-only** : WebWorkspace n'appelle QUE list_projects, open_project, get_project_work_state (via gateways DI). N'appelle PAS onDomainEvent/health/firstRunState → aucune commande hors-allowlist, pas de WS (live update = F3/B5, snapshot ponctuel pour l'instant).
**À confirmer B4** : get_project_work_state dans l'allowlist ; open_project sans effet de bord dangereux en read-only ; 401 (pas 403) sur cookie manquant ; code HTTP mauvais code /api/pair (401/403 → « Code d'appairage invalide »).
Build vert, garde no-direct-invoke verte, 79 fichiers/736 tests verts, desktop inchangé. Suite de [[ticket13-f1-http-ws-adapter-delivered]] ; inventaire [[ticket13-f0-frontend-transport-inventory]].

View File

@ -0,0 +1,19 @@
---
name: ticket13-f3-xterm-websocket-delivered
description: L'adapter WS terminal (round-trip xterm, reconnexion+replay, états connexion) du chantier client/serveur #13 est finalisé et vert côté frontend.
metadata:
type: reference
---
Ticket #13 lot F3 livré sur feature/ticket13-pty-websocket. Finalise l'adapter WS terminal depuis le squelette F1. Travail 100% dans frontend/src/adapters/http/ ; port TerminalGateway/TerminalHandle et TerminalView INCHANGÉS.
**wsLiveClient.ts** : machine d'état connexion (connecting/connected/reconnecting/closed, getConnectionState()+onConnectionStateChange), reconnexion auto (backoff, setTimeout injectable) → re-attach_terminal avec lastSeq + repaint scrollback borné + notices « déconnecté »/« reconnecté » écrites dans xterm via le sink. Suivi des sessions terminales (map `terminals`) pour le replay. Routage terminal.status exited → notice + onStatus + untrack. openTerminal/attachTerminal/detachTerminal/closeTerminalSession haut-niveau. API bas-niveau F1 (setOutputSink/send/domain events) conservée pour agent/system gateways.
**streamGateways.ts** : HttpTerminalGateway délègue aux nouvelles méthodes ; makeWsTerminalHandle.detach→detachTerminal (untrack, PTY vivant), close→closeTerminalSession (tue).
**frames.ts** : AttachedPayload.status? + StatusPayload.
**Contrat B5 (server.rs) confirmé** : frames terminal.open{cwd,rows,cols} (pas de projectId)/attach{sessionId,rows,cols,lastSeq}/input{sessionId,bytesBase64}/resize/detach/close/ping ↔ terminal.attached{session,scrollback:[{seq,bytesBase64}],nextSeq,status,gap,assignedConversationId}/output{sessionId,seq,bytesBase64}/status{sessionId,status,exitCode}/error/pong. Ack unifié terminal.attached. Scrollback = 1 entrée seq:0 (tous octets) ou vide.
**Écarts B5 à arbitrer** : (1) pas de replay delta — le serveur rejoue TOUT le scrollback, lastSeq ne sert qu'au flag gap ⇒ duplication possible à la reconnexion (conforme « V1 scrollback borné »). (2) multi-onglets « dernier gagne » SILENCIEUX — l'attachement évincé ne reçoit aucune frame (pas de crash, mais pas d'indication). (3) indication d'état = notices dans xterm (port inchangé).
**Tests** : terminalGateway.test.ts (round-trip), wsLiveClientReconnect.test.ts (états/reconnexion/exited). Build vert, garde no-direct-invoke verte, 81 fichiers/743 tests verts, desktop inchangé.
**Bloqueur run live** (dette carnet, hors F3) : `idea --serve` ne sert pas les assets web same-origin ⇒ app web pas lançable en navigateur tant que le lot « servir dist/ » n'est pas fait. Suite de [[ticket13-f1-http-ws-adapter-delivered]], [[ticket13-f2-web-readonly-client-delivered]].

View File

@ -0,0 +1,19 @@
---
name: ticket13-f4-web-agent-surface-delivered
description: L'agent CLI web (agent.launch → terminal.attached, réattache sans relance, cellule agent réutilisant TerminalView) du chantier client/serveur #13 est livré et vert côté frontend.
metadata:
type: reference
---
Ticket #13 lot F4 livré sur feature/ticket13-pty-websocket. Rend la surface agent fonctionnelle en mode web via les gateways DI ; CLI serveur, web = affichage.
**Adapter** : wsLiveClient.launchAgent(params) réutilise attachInternal de F3 → frame agent.launch, ack unifié terminal.attached, session trackée dans la map `terminals` (reconnexion/replay/exited comme un terminal), renvoie {sessionId, scrollback, assignedConversationId, status}. HttpAgentGateway.launchAgent → ws.launchAgent (pose assignedConversationId sur le handle) ; HttpAgentGateway.reattach → ws.attachTerminal (frame terminal.attach, PAS de relance). Chemin bas-niveau F1 dupliqué supprimé.
**UI (câblage, pas de nouveau composant terminal)** : features/web/WebAgentCell.tsx réutilise TerminalView (agentMode) avec agent gateway DI comme open=launchAgent/reattach=reattach, persiste sessionId. WebWorkspace : affordance « Ouvrir » par agent du snapshot work-state → monte WebAgentCell.
**Contrat B6 (server.rs) confirmé, aucun écart** : agent.launch payload plat camelCase {projectId,agentId,nodeId,rows,cols,conversationId} → ack terminal.attached{assignedConversationId}. Agent structuré → erreur UNSUPPORTED (canal PTY-only) surfacée par la bannière TerminalView. Réattache = terminal.attach (no respawn). Singleton guard AGENT_ALREADY_RUNNING déjà géré par TerminalView.
**Points UI à signaler** : (1) l'affordance liste les agents du snapshot work-state ; lister tous les agents exigerait list_agents sur l'allowlist B4. (2) write-portal (injection délégation) NON câblé en web V1 (affichage + frappe seulement). (3) WebAgentCell ne gère pas de nœud layout.
**Tests** : adapters/http/agentGateway.test.ts (launch/assignedConversationId/reattach/input/output/resize/UNSUPPORTED/NOT_FOUND), WebApp.test.tsx (+ouverture cellule). Build vert, garde no-direct-invoke verte, 82 fichiers/749 tests verts, desktop inchangé.
**Bloqueur run live** (dette carnet, hors F4) : `idea --serve` ne sert pas les assets web same-origin ⇒ round-trip navigateur pas validable tant que le lot « servir dist/ » n'est pas fait. Suite de [[ticket13-f3-xterm-websocket-delivered]], [[ticket13-f1-http-ws-adapter-delivered]], [[ticket13-f2-web-readonly-client-delivered]].

View File

@ -0,0 +1,17 @@
---
name: ticket13-f5-web-live-surfaces-delivered
description: Les surfaces live web (workstate live via event.domain, background tasks cancel/retry, inbox, re-synchro au reconnect) du chantier client/serveur #13 sont livrées et vertes.
metadata:
type: reference
---
Ticket #13 lot F5 livré sur feature/ticket13-pty-websocket. Rend les surfaces live fonctionnelles en mode web.
**Réutilisation clé** : le hook desktop transport-neutre `features/workstate/useProjectWorkState` (refresh du read-model sur event.domain) est réutilisé TEL QUEL — c'est lui qui donne la parité live. PAS de réutilisation de ProjectWorkStatePanel (dépend de useLayout + attach/stop-vers-cellule, spécifiques au grid desktop, hors read-only). WebWorkspace rend une vue lean : agents live/idle/busy, background tasks (Cancel/Retry via workState gateway), inbox par agent, + cellule agent F4.
**Adapter** : wsLiveClient.needsReconnect() = terminals.size>0 OU domainEventHandler!=null → la reconnexion marche aussi pour un abonnement live sans terminal (le handler domaine persiste à travers la reconnexion). Nouveau webLive.ts = singleton getWebLiveClient()/setWebLiveClient() (createHttpWsGateways enregistre le ws) exposant l'état de connexion au feature web SANS le mettre dans le port SystemGateway. Nouveau hook features/web/useLiveReconnect.ts : re-refresh du read-model sur transition reconnecting→connected (events manqués pendant coupure ; récupération = re-fetch complet du snapshot, pas de replay serveur).
**À confirmer B7** : (1) cancel_background_task/retry_background_task sur l'allowlist web write. (2) inbox surfacée via le read-model workstate, PAS via un flux notifications distinct (si B7 en a un, non câblé). (3) re-synchro = re-fetch complet (workstate = snapshot complet), pas de delta par event.
**Tests** : WebWorkspaceLive.test.tsx (event.domain→refresh, background render+cancel, reconnect re-sync), wsLiveClientReconnect (reconnexion pour abonnement domaine). Build vert, garde no-direct-invoke verte, 83 fichiers/753 tests verts, desktop inchangé.
**Bloqueur run live** (dette carnet, hors F5) : `idea --serve` ne sert pas les assets web same-origin. Suite de [[ticket13-f4-web-agent-surface-delivered]], [[ticket13-f3-xterm-websocket-delivered]], [[ticket13-f2-web-readonly-client-delivered]].

View File

@ -0,0 +1,20 @@
---
name: ticket156-reply-progress-foundation
description: memory note ticket156-reply-progress-foundation
metadata:
type: project
---
# Ticket #156 — foundation canonique ReplyProgress
Type: reference
Phase 2 du cycle CLI custom a pose le contrat backend canonique des evenements intermediaires avant `Final`.
Decisions livrees :
- Domaine : `ReplyProgress` + `ReplyProgressSource` (`ProviderNative` vs `IdeaLocal`) + `ReplyProgressKind` (`Turn`, `Message`, `Tool`, `Mcp`, `Other`) + `ReplyProgressStage` (`Started`, `Delta`, `Completed`, `Info`) dans `domain::ports`.
- `ReplyEvent::Progress { progress }` est explicitement non terminal ; `ReadinessPolicy` et les drains applicatifs continuent de donner autorite uniquement a `ReplyEvent::Final` pour la fin de tour. `RateLimited` reste orthogonal/non terminal.
- DTO transport : `ReplyChunk::Progress { progress }` avec shape JSON camelCase, additive par rapport aux anciens chunks.
- `agent_send` utilise maintenant `AgentSession::send_with_tap` pour projeter best-effort les progress pendant que `send` tourne ; le `ReplyStream` retourne par l'adapter reste le chemin autoritaire draine jusqu'au `Final`.
- Mapping adapters : Claude/Codex/OpenCode emettent des progress `ProviderNative` pour les evenements natifs observables (turn/system/step/tool item). OpenAI-compatible emet des progress `IdeaLocal`/`Mcp` autour des appels d'outils orchestries par IdeA.
Garde-fous : ne pas promettre le streaming du raisonnement interne ; ne jamais parser les metadonnees provider comme autorite metier ; #157 doit consommer `ReplyChunk::Progress` cote UI pour affichage distinct et degrade proprement si absent.

View File

@ -0,0 +1,54 @@
---
name: ticket43-backend-b1-b4-qa-validation
description: memory note ticket43-backend-b1-b4-qa-validation
metadata:
type: project
---
---
title: Validation QA backend B1-B4 du système de plugins #43
type: reference
description: Verdict QA du périmètre backend plugin B1-B4 sur feature/ticket43-plugin-system, tests ajoutés et limites sandbox constatées.
---
# Validation QA backend B1-B4 du système de plugins #43
Sur `feature/ticket43-plugin-system`, QA a validé le périmètre backend B1-B4 sans modifier le frontend.
Tests/ajustements QA ajoutés :
- `crates/domain/tests/layout.rs` : les helpers de tests existants ignorent explicitement `LayoutNode::CustomPluginLayout(_)`, ce qui rétablit l'exhaustivité de compilation des tests domaine après l'ajout du layout plugin custom.
- `crates/application/src/plugin/mod.rs` : tests in-memory des ports plugin pour vérifier :
- catalogue runtime vide pour `Disabled`, `PendingUninstall`, `Invalid` ;
- réconciliation MCP limitée aux plugins enabled + serveurs `autoStart`, identité `plugin:<pluginId>:<serverId>` et résolution sous `pluginRoot` ;
- disable stoppe le MCP, publie `PluginDisabled`, retire le plugin du runtime catalog ;
- uninstall stoppe le MCP, retire registry + package et publie `PluginUninstalled`.
Commandes vertes constatées :
```text
cargo test -p application plugin --offline --no-fail-fast
# 7 passed; 0 failed
cargo test -p domain -p application -p infrastructure -p backend -p app-tauri plugin --offline --no-fail-fast
# plugin-filtered targeted suite green; application 7 plugin tests, domain 3 plugin tests,
# serde roundtrip custom plugin layout, infrastructure 3 plugin tests, dto plugin filtered test all ok.
cargo test -p app-tauri --test dto_plugins --offline --no-fail-fast
# 2 passed; 0 failed
cargo fmt --check
# OK
```
Workspace complet :
```text
cargo test --workspace --offline --no-fail-fast -- --test-threads=1
```
Résultat KO attendu dans ce sandbox, hors périmètre plugin :
- `-p infrastructure --lib` : 10 échecs `session::openai_compat::*` sur `bind: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }`.
- `-p web-server --lib` : 2 échecs de bind `127.0.0.1:0 Operation not permitted` et 5 scénarios websocket/terminal recevant `error` au lieu de `terminal.attached`, cohérents avec restrictions loopback/PTY du sandbox.
Verdict : backend plugins B1-B4 validé QA avec réserve uniquement environnementale sur le workspace global.

View File

@ -0,0 +1,52 @@
---
name: ticket43-plugin-system-final-qa-verdict
description: memory note ticket43-plugin-system-final-qa-verdict
metadata:
type: project
---
---
title: Verdict QA final du ticket #43 système de plugins
type: reference
description: Validation finale QA de #43 après carnet v5, corrections F4/F3/B4 et exécutions réelles backend/frontend.
---
# Verdict QA final du ticket #43 système de plugins
Branche validée : `feature/ticket43-plugin-system`.
Contexte : après verdict QA orange initial, Architect a figé le carnet v5 : `customPluginLayout` top-level canonique, `gitRepository` obligatoire en F3, `${appDataDir}` obligatoire en B4, et `agentSelected`/`terminalFocused`/`layoutCellFocused` + persistance backend state layout plugin acceptés comme dette v1.
Résultats réels exécutés par QA :
```text
cargo test -p domain -p application -p infrastructure -p backend -p app-tauri plugin --offline --no-fail-fast
# OK
# application plugin: 9 passed
# domain plugin: 3 passed
# infrastructure plugin: 5 passed
# custom_plugin_layout_roundtrips_with_opaque_state: ok
cd frontend && npm run typecheck
# exit 0
cd frontend && npm test -- --run
# Test Files 104 passed (104)
# Tests 947 passed (947)
```
Contrôles ciblés confirmés :
- Frontend `LayoutNode` inclut `{ type: "customPluginLayout"; node: CustomPluginLayoutCell }` top-level, sans contrat `LeafCell.pluginLayout`.
- `LayoutGrid` route `customPluginLayout` vers `PluginLayoutCellView`.
- `onStateChange`, `onOpenPlugins`, `onChooseAnotherLayout` sont câblés in-session (`setPluginLayoutState`, navigation settings plugins, remplacement par terminal).
- `ProjectsView` câble `gitRepository` via `GitGateway.branches(active.id)` ; `agentSelected`, `terminalFocused`, `layoutCellFocused` restent explicitement `false` en dette v1.
- Backend application substitue `${pluginRoot}` et `${appDataDir}` dans command/args/env/cwd des specs MCP plugin, avec test `reconcile_mcp_substitutes_app_data_dir_in_plugin_server_specs`.
Verdict QA : VERT pour merge local du ticket #43.
Dette v1 assumée :
- `agentSelected`, `terminalFocused`, `layoutCellFocused` non câblés, figés à `false` jusqu'à un lot focus/selection dédié.
- Persistance backend du `state` de layout plugin non implémentée ; F4 validé en in-session selon arbitrage Architect.
Aucun nouveau blocage détecté dans les suites demandées.

View File

@ -0,0 +1,15 @@
---
name: ticket54-f1-model-download-overlay-frontend
description: Overlay plein-cellule de préparation du serveur modèle local + progression (barre/%/bytes/source), corrélation factorisée, priorité de voile.
metadata:
type: reference
---
Ticket #54 livré et vert côté frontend (F1 = overlay, F2 = progression).
**Contrat** : `ModelServerStatus.downloading { downloadedBytes|totalBytes|percent|source: number|string|null }` (`frontend/src/domain/index.ts`), miroir exact de `ModelServerStatusDto` (`crates/app-tauri/src/events.rs`). Event `modelServerStatusChanged` passé tel quel — pas de mapping de désérialisation.
**Factorisation** dans `frontend/src/features/agents/modelServerLaunch.ts` : `correlateModelServerStatus` (chaîne `agentId→profileId→opencode.localModelServerId→serverId`), `modelServerOverlayText` (titre+gating de voile), `useModelServerLaunchState(projectId)` (source autonome pour LeafView), et F2 : `formatBytes` (SI base 1000 : o/Ko/Mo/Go) + `describeModelServerDownload``{percent(clamp 0..100 ou null=indéterminé), bytesLabel, source}` (null hors `downloading`). AgentsPanel réutilise le helper.
**Overlay** dans `LeafView`/`LayoutGrid.tsx` (`data-testid=model-server-overlay`, `zIndex CELL_Z.veil`) : titre + barre `role=progressbar` (aria-valuenow seulement en déterminé, sinon barre indéterminée via keyframe `model-server-indeterminate` dans `theme.css`) + label `"X % · A Mo / B Mo"` + ligne source HF. `starting`/`probing` = titre seul, pas de barre. **Priorité : voile modèle au-dessus** des voiles write-portal + F3 (les deux gatés sur `!modelServerOverlay`). Voir [[ticket4-overlay-composition-leafview]].
Tests : `LayoutGrid.modelServerOverlay.test.tsx` (F1+F2, dont multi-cellules & indéterminé) + unitaire pur `modelServerLaunch.test.ts`. Non-régression `src/features/agents src/features/layout` = 202 verts ; `npx tsc --noEmit` clean.

View File

@ -0,0 +1,19 @@
---
name: ticket56-visibleelsewhere-derives-from-layout
description: Fix frontend du sélecteur d'agent : la désactivation « visible ailleurs » doit venir du layout courant, pas du dernier nodeId du live registry.
metadata:
type: reference
---
Bug #56 : agent X affiché en cellule A → A bascule sur Y → X désactivé (« visible ailleurs ») en cellule B alors que X n'est plus affiché nulle part.
Cause : le live registry garde X→nodeId A même après le swap ; `LayoutGrid.visibleElsewhere` lisait `live.nodeId` comme « affiché ici ».
Fix (frontend pur, ne tue pas la session) dans `frontend/src/features/layout/LayoutGrid.tsx` :
- `visibleElsewhere(candidate)` dérive du **layout courant** : truthy uniquement s'il existe une feuille visible ≠ cellule courante avec `leaf.agent === candidate`. Retourne `{ nodeId }`.
- `backgroundLive` utilise `!visibleElsewhere(candidate)` au lieu de `!visibleNodeIds.has(live.nodeId)` ; garde `live.nodeId === id` (anti-boucle self-launch).
- onChange du select : même dérivation ; sélection inchangée (attachLiveAgent si sessionId sinon setCellAgent).
- Prop `visibleNodeIds` supprimé (devenu mort) de tout le threading LayoutGrid→NodeView→Split/Grid/Leaf.
Invariant préservé : agent réellement épinglé dans une cellule visible reste NON sélectionnable ailleurs.
Piège de test : un test qui mocke `listLiveAgents` avec un nodeId visible mais **sans** épingler l'agent dans ce leaf ne désactive plus rien — il faut `setCellAgent` réel. Tests dans `singletonAgent.test.tsx` (describe « ticket #56 » + ajustement R0d). Suite frontend : 706 verts.

View File

@ -0,0 +1,18 @@
---
name: ticket74-f1-web-bundle-transport-seam
description: Deux artefacts Vite (dist/dist-web), mode `web` portable Windows, et le câblage anti-divergence de la constante de transport.
metadata:
type: reference
---
Le frontend produit **deux** artefacts Vite depuis les mêmes sources :
- `frontend/dist` → transport `tauri` (desktop, `build.frontendDist`) — `npm run build`.
- `frontend/dist-web` → transport `http` (packagé en ressource Tauri `web/`) — `npm run build:web`.
- `npm run build:bundle` produit les deux : c'est le point d'entrée du packaging Tauri.
**Le mode web passe par `--mode web` + `frontend/.env.web` (`VITE_TRANSPORT=http`), jamais par un préfixe inline `VITE_TRANSPORT=http vite build`** : non portable Windows/NSIS, cible active du bundle. `.env.web` est versionné (non gitignoré) ; `dist-web/` est ignoré.
**Anti-divergence de `__IDEA_TRANSPORT__`** : `frontend/src/app/transport.ts` expose `transportFromEnv(value)`, importé à la fois par `di.tsx` (`resolveTransport`/`shouldUseHttp`) et par `vite.config.ts`, qui lui passe `VITE_TRANSPORT` via `loadEnv(mode)`. Même variable + même prédicat = une seule source. Modifier le prédicat déplace constante et runtime ensemble. `vitest.config.ts` réplique le `define` via le même helper.
La constante est **publiée sur `window` dans `main.tsx`** : `define` ne remplace que les occurrences existantes et une constante non référencée serait tree-shakée ; l'affectation est un effet de bord qui survit à la minification. Elle reporte le transport hors mock (`VITE_USE_MOCK` reste un switch distinct).
Pour identifier le transport d'un bundle bâti : `grep -o '__IDEA_TRANSPORT__="[a-z]*"' dist*/assets/*.js`. **Ne pas se fier à la présence de `__TAURI_INTERNALS__` ni à un nom de symbole minifié** : les deux jeux d'adapters sont présents dans les deux bundles, un grep ne les discrimine pas.

View File

@ -0,0 +1,31 @@
---
name: ticket95-adapter-aware-liveness-probe
description: memory note ticket95-adapter-aware-liveness-probe
metadata:
type: project
---
# #95 — Sonde de vivacité du rendez-vous devenue adapter-consciente
**Type :** correctif architecture / bug racine. Livré sur `feature/rendezvous-liveness-probe-per-adapter` (commit 376fc9f), AppImage 0.3.0 rebuildée.
## Bug racine
Le rendez-vous `idea_ask_agent` (`run_inactivity_watchdog`, `crates/application/src/orchestrator/rendezvous.rs`) coupe en **faux `NoReply`** toute cible **structurée** dont le tour dépasse la fenêtre d'inactivité (défaut 600 s, = `turn_timeout_ms` du profil cible). Cause : la seule sonde de vivacité (`transcript_activity_token`) lisait le transcript Claude (`~/.claude/projects/<encoded-cwd>/*.jsonl`) — invisible pour OpenCode/Codex, et fragilise même Claude en mode `-p` headless si le transcript ne grossit pas mi-tour. `has_probe=true` mais la sonde renvoie `None` ⇒ bras `(true,_,None)=>false` ⇒ aucun réarmement ⇒ NoReply à la première fenêtre.
## Fix (architecture figée)
1. **Port domaine** (`crates/domain/src/ports.rs`) : `AgentSession::activity_token() -> Option<u64>` (défaut `None`, zéro régression). Jeton monotone = « la session travaille ».
2. **Machinerie** (`crates/infrastructure/src/session/process.rs`) : `run_turn_with_activity(...)` bump un `Arc<AtomicU64>` à **chaque ligne stdout lue** (drain async ET drain sandboxé thread). `run_turn` (4 args) délègue avec `None` ⇒ les ~11 call sites de test sont intacts.
3. **Sessions** : `ClaudeSdkSession`, `CodexExecSession`, `OpenAiCompatibleSession` overrident `activity_token()` via `run_turn_with_activity` ; `OpenCodeSession` (drain inline) bump son propre compteur par ligne JSONL.
4. **Sonde composite** (`resolve_ask_liveness_token`, `crates/backend/src/lib.rs`) : préfère `session.activity_token()` de la session vivante (`structured.session_for_agent`), repli inchangé sur le transcript Claude. Câblée par `.with_ask_liveness_probe`.
## Contrats clés
- `has_probe` reste `true` dès qu'une sonde est câblée ; la sonde composite renvoie désormais `Some(token)` qui avance ⇒ la fenêtre se réarme. Le repli transcript Claude couvre le cas « session vivante sans override ».
- La fenêtre = `turn_timeout_ms` du **profil cible** (`turn_timeout_for``liveness_for_agent`), défaut `ASK_AGENT_TIMEOUT` 600 s. **Pas d'env global pour la fenêtre** (seul le plafond a `IDEA_ASK_RENDEZVOUS_CEILING_MS`, défaut 4 h).
- Pour un test live rapide sans attendre 600 s : mettre un petit `turn_timeout_ms` (ex. 20 000) sur le profil de la cible, puis déléguer une tâche de ~60-90 s.
## État validation
- Tests unitaires verts : `run_turn_with_activity_bumps_counter_per_line`, `*_session_activity_token_advances_across_a_turn` (claude/codex/opencode), + la sonde composite backend + le watchdog rendezvous existants.
- AppImage 0.3.0 rebuildée + installée (`/home/anthony/Documents/IdeA_0.3.0_amd64.AppImage`, backup `.old-pre95fix`). **Relance IdeA requise** pour l'activer (le binaire qui tourne = AppImage en mémoire ; relancer depuis l'intérieur tue la session courante).
## À noter (dette / hors périmètre)
- #96 (EffectivePermissions assistants de ticket) laissé ouvert, documenté dans le carnet #96 (décision produit différée).
- Le souvenir utilisateur initial décrivait un échec « demandeur GLM/OpenCode → cible Claude ». Mécaniquement le watchdog est **ciblé-cible** (keyed sur l'agent cible) : un échec sur cible Claude longue n'est possible que si le transcript Claude `-p` ne grossit pas mi-tour (couvert désormais par l'`activity_token` de ClaudeSdkSession). La théorie principale reste « cible structurée longue non observée → faux NoReply ».

View File

@ -0,0 +1,35 @@
---
name: ticket97-opencode-provider-mutual-exclusion
description: memory note ticket97-opencode-provider-mutual-exclusion
metadata:
type: project
---
# Ticket #97 — Exclusion mutuelle opencode / opencodeProvider (décision Architect)
## Bug
Wizard first-run : profiles.json contient à la fois `opencode` (llamacpp) et `opencodeProvider` (cloud). Lecture priorise `opencode` → llamacpp l'emporte silencieusement.
## Root cause (vérifiée dans le code)
1. `SaveOpenCodeProviderProfile::execute` (`crates/application/src/agent/usecases.rs:364-367`) pose `opencode_provider` sans faire `opencode = None`.
2. Invariant `opencode_backend_is_consistent` (`crates/domain/src/profile.rs:1220`) existe + testé mais **jamais appelé** hors tests (garde morte).
3. Lecture priorise `opencode` : `crates/application/src/agent/lifecycle.rs:2367` + `crates/infrastructure/src/assistant/mod.rs:252`.
## Décisions Architect (validées)
- **Lot** : un seul lot cohérent. Backend = autoritaire (invariant + garde + use case via builder + migration). Frontend = strip de la config inactive au save selon le mode (requis pour les chemins SaveProfile/ConfigureProfiles qui ne portent pas d'intention explicite). Découplés/parallélisables. DevBackend + DevFrontend + QA.
- **Frontière** :
- Domaine : builders `with_opencode` (`profile.rs:1132`) et `with_opencode_provider` (`profile.rs:1140`) doivent imposer l'exclusion mutuelle (chacun efface l'autre). Aujourd'hui ce sont des setters muets = la faille.
- Infrastructure : `FsProfileStore::save` rejette tout profil violant l'invariant → `AppError::Invalid` (c'est ici que le prédicat enfin s'appelle). Défense en profondeur.
- Application : use cases utilisent les builders, jamais la mutation brute de champ.
- Refuser l'ad-hoc `opencode = None` par use case (DRY, 4 chemins d'écriture).
- **DTO** : garder `SaveOpenCodeProviderProfileRequestDto` (`dto.rs:1148`) whole-profile (zéro cassure frontend). Le `opencode` parasite devient inoffensif car le use case reconstruit via builder. Output = profil normalisé, autorité pour le frontend. Corriger aussi SaveProfile (`usecases.rs:269`) et ConfigureProfiles (`usecases.rs:460`).
- **Lecture priorité** : garder `opencode` d'abord (irrelevant post-exclusion), commenter comme fallback défensif.
- **Duplication résolution** (lifecycle.rs:2367 + assistant/mod.rs:252) : dette hexagonale préexistante, NE PAS élargir ce lot. Suivre via un futur `AgentProfile::effective_opencode_backend()` ou générateur partagé.
- **Migration REQUISE** : profils déjà corrompus sur disque portent les deux. Recovery : à la lecture (ou passe de migration), quand les deux présents, dropper `opencode` stale (l'intention est cloud, le bug ne venant que d'une action cloud explicite). Sans cela, #97 ne corrige que les nouveaux profils.
## Sites de résolution (priorité) = exactement 2
- `crates/application/src/agent/lifecycle.rs:2367`
- `crates/infrastructure/src/assistant/mod.rs:252`
Autres accès `.opencode` scoper en mode local, non affectés : `lifecycle.rs:2455-2468`, `model_server.rs:121-127`, `catalogue.rs:244-258`, `usecases.rs:410`.
## Statut
Décision Architect posée. À faire implémenter par DevBackend (domaine builders + garde store + migration + use cases) et DevFrontend (strip au save). QA : tests domaine/store + intégration cloud + scénario migration profils corrompus.

View File

@ -0,0 +1,83 @@
---
name: ticket98-opencode-modelsdev-cache-seed
description: memory note ticket98-opencode-modelsdev-cache-seed
metadata:
type: project
---
---
slug: ticket98-opencode-modelsdev-cache-seed
title: "Ticket #98 — Fix spawn OpenCode : seed du cache models.dev isolé (approche B2)"
type: reference
description: Cadrage figé du fix #98 (modèle écrasé par glm-5.2 au spawn pour provider catalogue cloud ex: zai) : cause racine = asymétrie picker↔spawn, approche B2 = semer best-effort le cache models.dev hôte dans le XDG_CACHE_HOME isolé.
---
# Ticket #98 — Fix spawn OpenCode : seed du cache models.dev isolé
## Symptôme
Wizard profil OpenCode first-run : provider catalogue cloud (ex: zai/ZAI Code) + modèle choisi → après sauvegarde l'agent tourne en `glm-5.2` quel que soit le modèle. Persistance correcte (`profiles.json` conserve `opencodeProvider.model`). `glm-5.2` est le **fallback interne d'OpenCode**, absent du code IdeA.
## Cause racine (confirmée + affinée par Architect)
**Asymétrie picker↔spawn**, pas seulement « pas de bloc models » :
1. **Picker** (`provider_catalogue.rs:79-84,150-153`) : lit le cache models.dev via `opencode_models_cache_path()` qui résout le **vrai** cache hôte (`XDG_CACHE_HOME ?? ~/.cache`). Permet d'afficher zai + ses modèles.
2. **Spawn** (`lifecycle.rs:2386,2400-2407` ; `assistant/mod.rs:272,277-285`) : IdeA **ré-isole** `XDG_CACHE_HOME``.opencode/cache` **vide** sous `run_dir`. OpenCode ne voit plus le cache.
3. **Rendu** (`opencode_provider_config_json`, `lifecycle.rs:2795-2821` / `assistant/mod.rs:446-466`) : pour `config.custom == None` (défaut pour zai), IdeA n'émet que `apiKey` + `model: "zai/<m>"`, **sans** bloc `models`. Correct **uniquement** pour les 3 built-ins hardcodés dans le binaire OpenCode (`anthropic`, `openai`, `openrouter`).
→ OpenCode reçoit `model: "zai/<m>"`, ne reconnaît pas zai comme built-in, ne trouve pas le cache models.dev (isolé vide) → fallback silencieux glm-5.2.
- **Local/custom marchent** : émettent un bloc `models` auto-suffisant (`assistant/mod.rs:364-381`, `:447-460`).
- **3 built-ins marchent** : hardcodés dans OpenCode.
- Bug ne touche **que** les providers connus d'OpenCode *exclusivement via models.dev*.
## Approche figée : **B2 — Semer le cache models.dev isolé depuis le cache hôte**
Après création du `XDG_CACHE_HOME` isolé, copier **best-effort** le fichier cache models.dev hôte (`opencode_models_cache_path()``<isolated_cache>/opencode/models.json`) via le port `FileSystem`. Lecture hôte = `std::fs` (identique au picker) ; écriture dans la home isolée.
**Pourquoi pas les autres :**
- **(A)** Émettre un bloc `models`+`npm`+`baseURL` pour les catalogue → **écartée en v1** : IdeA devrait capturer le bon `npm` AI-SDK par provider depuis models.dev (`@ai-sdk/anthropic` vs `openai-compatible`…) — dupliquerait la connaissance du registry OpenCode (violation OCP), risque de régression built-ins. Gardée en **escalade** si B2 défait par refresh.
- **(B1)** Pointer vers le vrai cache hôte (ne plus isoler) → **écartée** : casse l'isolation en écriture (pollution + race entre sessions).
- **(C)** Bundler une copie statique models.dev dans IdeA → **écartée** : staleness + diverge picker/spawn.
**Auto-cohérence B2** : la précondition du bug (cache hôte présent au picker) garantit la précondition du fix (fichier à copier au spawn). Cache hôte absent → picker ne montre que les 3 built-ins → bug non atteint → fix non requis.
## Contrat figé
### Ports / DTO
- **Aucun nouveau port / entité domaine / DTO modifié.** Réutilise le port `FileSystem` déjà injecté sur le chemin spawn. Lecture source = `std::fs` hôte (mécanisme identique au picker).
- Rendre **publique** `opencode_models_cache_path()` (source de vérité unique — encode le workaround du bug upstream #8235 ; ne **pas** re-dériver).
### Fichiers (périmètre DevBackend)
- `crates/application/src/agent/provider_catalogue.rs` — exposer `opencode_models_cache_path()` en `pub` (ou ajouter `pub fn read_models_dev_cache_bytes() -> Option<Vec<u8>>`).
- `crates/application/src/agent/mod.rs` — re-export.
- `crates/application/src/agent/lifecycle.rs` — branche `apply_mcp_config` (≈2382-2408) : après `create_dir_all` du cache + création `xdg_cache`, semer `<xdg_cache>/opencode/models.json` depuis le cache hôte, best-effort. Branche **commune** opencode + opencodeProvider.
- `crates/infrastructure/src/assistant/mod.rs` — branche miroir (≈268-285) : même appel.
- **Factoriser** : `application::agent::seed_opencode_models_cache(fs: &dyn FileSystem, isolated_cache_dir: &str)` appelée par les deux sites. Partie **pure** testable `seed_from_bytes(fs, dest, src_bytes)` ; wrapper impur `std::fs::read` fin.
### Invariants (stricts)
1. Isolation préservée en **écriture** : HOME, XDG_CONFIG_HOME, XDG_DATA_HOME, XDG_CACHE_HOME restent sous `run_dir`. Aucune var d'env repointée vers l'hôte. Seul le **contenu** du cache isolé est semé (lecture seule).
2. **Best-effort, n'échoue jamais le launch** : source absente/illisible ou erreur FS → pas d'échec du spawn. Symétrique du contrat best-effort existant de `apply_mcp_config` (`lifecycle.rs:2422-2425`). ≠ `resolve_opencode_provider_api_key` (échec dur). Le seed est **mou**.
3. Pas de régression local/custom : `opencode_config_json` (llamacpp) et `opencode_provider_config_json(custom==Some)` **byte-identiques** (rendu non touché ; seed additif orthogonal).
4. Pas de régression built-ins : anthropic/openai/openrouter (`custom==None`, hardcodés) restent fonctionnels.
5. Exclusion mutuelle `opencode` vs `opencodeProvider` (#97) : non touchée.
6. Source de vérité unique du chemin models.dev : `opencode_models_cache_path()` réutilisée.
7. Cohérence picker↔spawn : modèles résolvables au spawn = sur-ensemble de ceux du picker (même fichier source).
### Hors périmètre (ne pas faire ici)
- Résolution providers pour **projets remote (SSH/WSL)** (picker lit déjà le cache hôte — incohérence pré-existante). Fix corrige le cas **local**, ne régresse pas le remote.
- Déduplication du rendu lifecycle↔infra (`opencode_provider_config_json` ×2) — on factorise **uniquement le seeder**.
- Aucune modif UI/wizard.
## QA — 2 couches
1. **Unitaire `application`** (automatisable, déterministe) :
- Partie pure `seed_from_bytes(fs, dest, src_bytes)` : bytes présents → assert `<dest>/opencode/models.json` écrit identique ; `None` → aucun fichier **et** pas d'erreur.
- Non-régression rendu : JSON de `opencode_config_json` et `opencode_provider_config_json(custom==Some/None)` byte-identiques (tests existants `lifecycle.rs:4428+` verts).
- ⇒ Ne prouve **pas** la résolution réelle par OpenCode.
2. **Intégration / réelle-exécution (gated, propriété QA)** : spawn réel d'OpenCode avec profil `zai` (`custom==None`) contre un cache models.dev fixture contenant `zai` ; assert **pas de fallback glm-5.2** (modèle `zai/<choix>` effectivement utilisé). Gater `#[ignore]`/env (clé API + réseau). **C'est ce test qui prouve le bug corrigé.**
## Risque résiduel + escalade
- **Inconnu empirique** : est-ce qu'OpenCode au démarrage tente de **rafraîchir** models.dev (écrase notre copie, ou hang sans réseau) ? `OPENCODE_DISABLE_AUTOUPDATE=1` ne vise que l'auto-update du binaire, pas sûr qu'il couvre le refresh models. **QA doit vérifier** sur le test d'intégration. Si le refresh défait B2 → **escalader vers (A)** : capturer `npm`+`baseURL` réels par provider dans le parseur models.dev et peupler `custom`.
## Topologie
- Branche : `feature/ticket98-opencode-modelsdev-cache-seed` depuis `develop@69e5878` (#97 exclusion mutuelle prérequis y est fusionné : `0f0a76d` + merge `5533073`). `crates/` propre.
- Carnet #98 version 2 = source de vérité du cadrage.
## Lié
- #97 (relatesTo) : exclusion mutuelle provider — prérequis livré.

View File

@ -0,0 +1,51 @@
---
name: tickets-70-100-102-ux-surface-scoping
description: memory note tickets-70-100-102-ux-surface-scoping
metadata:
type: project
---
---
title: Cadrage UX tickets #70 #100 #102 — modèles locaux et bugs terminal
type: design
description: Surface utilisateur attendue pour supprimer les modèles llama.cpp téléchargés, et règle UX pour les bugs de scroll/fit OpenCode qui doivent être corrigés sans nouvelle UI.
---
# Cadrage UX tickets #70 #100 #102
## #70 — Gestion des modèles locaux téléchargés
Ajouter une affordance humaine de suppression des artefacts de modèles téléchargés par les serveurs locaux llama.cpp, dans la surface existante `Local model servers` / configuration OpenCode locale.
Principes visibles :
- La suppression d'un serveur déclaré et la suppression du fichier modèle téléchargé sont deux actions distinctes.
- Une action destructive sur le fichier modèle doit être explicite, confirmée, et impossible pendant un usage actif/téléchargement du même artefact.
- Le libellé doit parler de `modèle téléchargé`, pas de cache interne ou chemin technique en premier niveau.
- Les modèles issus d'un `localPath` utilisateur ne doivent jamais être proposés à la suppression comme s'ils appartenaient à IdeA.
États attendus par serveur :
- Aucun modèle téléchargé connu : aucun bouton de suppression de modèle, ou bouton désactivé avec tooltip `Aucun modèle téléchargé par IdeA`.
- Modèle téléchargé disponible : bouton secondaire/destructif `Supprimer le modèle téléchargé`.
- Téléchargement/préparation en cours : action désactivée, texte `Téléchargement en cours`.
- Serveur/agent utilisant ce modèle : action désactivée, texte `Modèle utilisé par un agent en cours`.
- Suppression en cours : ligne locale occupée, action désactivée, message `Suppression du modèle...`.
- Succès : toast/status non bloquant `Modèle téléchargé supprimé` ; la configuration serveur reste présente.
- Échec : alerte inline `Impossible de supprimer le modèle téléchargé : <raison courte>`.
Confirmation :
- Titre : `Supprimer le modèle téléchargé ?`
- Corps : `Le serveur local restera configuré, mais IdeA devra retélécharger ce modèle au prochain lancement.`
- Si la taille est connue : ajouter `Espace libéré : <taille>.`
- Action principale destructive : `Supprimer le modèle`
- Action secondaire : `Annuler`
## #100 — Scroll OpenCode
Pas de décision UX spécifique. Le comportement attendu est celui d'une cellule terminal native : l'utilisateur peut remonter dans le scrollback OpenCode jusqu'à la limite de rétention disponible, avec molette, trackpad, scrollbar et clavier, sans blocage prématuré propre à OpenCode.
Ne pas ajouter de bouton, message ou mode spécial OpenCode. QA doit valider le comportement visible dans une cellule OpenCode longue.
## #102 — Fit TUI après switch/layout/ajout cellule
Pas de nouvelle surface UX spécifique. Le terminal doit s'afficher correctement automatiquement après switch de projet, switch de layout, ajout/suppression/split/resize de cellules et rattachement d'une session existante.
Ne pas afficher de message demandant à l'utilisateur de redimensionner. Éviter tout flash durable vide/noir ; un voile technique transitoire n'est acceptable que s'il reste très bref et non bloquant.

View File

@ -0,0 +1,53 @@
---
name: toolchain-rust-partage-acces-agents
description: memory note toolchain-rust-partage-acces-agents
metadata:
type: project
---
---
slug: toolchain-rust-partage-acces-agents
title: Accès au toolchain Rust/Tauri partagé pour tous les agents (isolement HOME OpenCode)
type: project
description: Le toolchain Rust stable est déjà installé sur la machine mais invisible aux agents car le profil OpenCode isole HOME. Diagnostic, atténuation par symlink, et chantier durable (injection env au spawn).
---
# Toolchain Rust/Tauri : pourquoi les agents ne compilaient pas, et comment les débloquer
## Symptôme (récurrent)
Tout agent (Main, DevBackend, QA,…) lancé sous un profil OpenCode ne peut PAS compiler le workspace Rust/Tauri :
- `cargo`/`rustc` = shims rustup qui répondent « no default toolchain » / « no installed toolchains ».
- Bloque toute validation backend (cargo check/build/test), fait timeout les délégations lourdes.
## Cause racine
- Le toolchain **stable 1.94.1 est DÉJÀ installé** dans `/home/anthony/.rustup` + `/home/anthony/.cargo` (toolchains + bin).
- MAIS le profil **OpenCode isole `HOME`** vers `.ideai/run/<agent_uuid>/.opencode/`. Donc `~/.rustup` et `~/.cargo` = `.opencode/.rustup` / `.opencode/.cargo`, qui ne contiennent qu'un `settings.toml` + un cache registry partiel → **aucun toolchain**.
- IdeA lui-même ne set **ni** `RUSTUP_HOME` **ni** `CARGO_HOME` (grep vide dans `crates/`). Le point d'extension existe pourtant : `crates/infrastructure/src/session/opencode.rs:237` (`cmd.env(key, value)`) set déjà des env au spawn.
- `target/` est dans le project root (partagé, géré par le lock cargo) → partageable sans conflit.
- `tauri` est dispo via `frontend/node_modules/.bin/tauri` (après `npm install` du frontend).
## Atténuation appliquée (2026-07-25, ops, sans rebuild)
Symlinker les homes isolés vers les homes partagés pour chaque run-dir agent :
```bash
for d in .ideai/run/*/.opencode; do
for sub in .rustup .cargo; do
p="$d/$sub"
[ -e "$p" ] && [ ! -L "$p" ] && { rm -rf "$p"; ln -s "/home/anthony/$sub" "$p"; }
done
done
```
Vérifié sur Main : `cargo 1.94.1` / `rustc 1.94.1` accessibles **sans aucune variable d'env explicite**. Symlink appliqué aux agents actifs (Main a6ced819, DevBackend 73c853d1, QA aefdbd61, …) — 5 run-dirs concernés.
**Tient pour les agents existants** : rustup suit les symlinks, et OpenCode ne recrée pas `$HOME/.rustup` s'il existe déjà.
## Solution DURABLE (chantier IdeA, à livrer)
Pour les **nouveaux** agents (IdeA crée un nouveau run-dir `.ideai/run/<uuid>/.opencode/.rustup` vide), il faut qu'IdeA provisionne l'accès au toolchain partagé automatiquement. Deux options équivalentes, à faire par DevBackend + **rebuild AppImage + relance** :
1. Au spawn de l'agent, injecter `RUSTUP_HOME=/home/anthony/.rustup` et `CARGO_HOME=/home/anthony/.cargo` (point d'extension `opencode.rs:237`). Valeurs résolues depuis le vrai HOME user (pas le HOME isolé), idéalement configurables (env projet / settings).
2. Ou, à la création du run-dir, créer les deux symlinks `.opencode/.rustup` et `.opencode/.cargo` → homes partagés.
Recommandation : option 1 (injection env) — moteur-agnostique (marche aussi pour Codex/Claude si un jour ils isolent aussi) et ne dépend pas du filesystem layout du moteur.
À grouper dans le **même rebuild AppImage** que le fix « sonde de vivacité multi-moteur » (cf. `idea-memory` à venir) — les deux sont des chantiers runtime qui nécessitent rebuild + relance.
## Liens
- Règle rebuild AppImage : `.ideai/skills/md/a72dac60-641c-4417-b0d7-94b8539f817a.md` (skill build AppImage), mémoire `mcp-bridge-and-delegation-runtime-notes`.
- Timeout délégation 600 s (autre symptôme sur les tâches lourdes) : mémoire `rendezvous-600s-cap-too-short-heavy-tasks` + sonde Claude-seule `crates/infrastructure/src/inspector/claude_paths.rs:89`.

View File

@ -0,0 +1,41 @@
---
name: ux-ai-profiles-opencode-persistence-list-coherence
description: memory note ux-ai-profiles-opencode-persistence-list-coherence
metadata:
type: project
---
---
title: UX — Cohérence profils IA/OpenCode entre éditeur et picker agents
type: decision
description: Décisions de surface pour corriger la création de profils OpenCode, la persistance visible après sauvegarde et la cohérence entre Settings > Profils IA et les sélecteurs d'agents.
---
# UX — Profils IA/OpenCode : création, persistance, liste unique
## Décision centrale
La liste visible dans `Settings > Profils IA` et les pickers de profils des agents doit représenter la même collection persistée de profils IA. Les profils de référence ne sont qu'une source d'ajout, pas une deuxième vérité visible.
## Comportement attendu
- Le bouton de création OpenCode s'appelle `Créer un profil OpenCode` dans la surface française.
- Cliquer sur ce bouton ajoute immédiatement une ligne de profil en brouillon, sélectionnée, éditable et clairement marquée non enregistrée tant que la sauvegarde n'a pas réussi.
- Chaque nouveau profil OpenCode doit avoir une identité distincte et un nom humain distinct par défaut, par exemple `OpenCode local 2`; l'utilisateur peut renommer avant sauvegarde.
- `Dupliquer` conserve la configuration du profil source mais crée une nouvelle identité et un nom suffixé, par exemple `(copie)`.
- `Enregistrer` persiste tous les profils sélectionnés/édités, puis recharge la liste depuis la source persistée. La liste affichée après succès doit être le résultat relu, pas seulement l'état local optimiste.
- Après sauvegarde réussie, le profil créé reste visible dans l'éditeur sans réouverture manuelle et apparaît dans le picker de création d'agent et dans le picker de changement de profil d'un agent existant.
- Les profils OpenCode ne doivent jamais être fusionnés/dédupliqués par commande, modèle, endpoint ou adapter. La déduplication visible se fait uniquement par `id`.
- En mode édition, les profils déjà configurés apparaissent en premier, pré-sélectionnés, avec leur configuration réelle intacte. Les profils de référence non configurés peuvent suivre comme suggestions non sélectionnées.
- Si un profil référencé par un agent n'existe plus dans la liste persistée, le picker de l'agent conserve l'id courant comme option orpheline lisible, sans le mélanger aux profils disponibles.
## États et feedback
- Pendant la création/clonage : bouton désactivé ou loading local, sans bloquer la détection CLI.
- Ligne brouillon : indicateur discret `Non enregistré` ou état visuel équivalent.
- Sauvegarde réussie : statut court `Profils enregistrés` puis disparition automatique.
- Échec sauvegarde : message d'erreur persistant, la ligne brouillon reste éditable et n'est pas perdue.
- Picker agents vide : ne pas encourager la saisie libre d'id comme chemin normal. Afficher plutôt un état vide actionnable vers `Profils IA`.
## Critères d'acceptation visuels
- Créer un profil OpenCode, sauvegarder, rester sur Settings : le profil est toujours visible après le retour succès.
- Sans fermer Settings, ouvrir/créer un agent : le même profil est disponible dans le picker.
- Deux profils OpenCode avec même endpoint/modèle mais ids distincts restent deux lignes et deux options distinctes.
- Renommer un profil puis sauvegarder met à jour le libellé dans l'éditeur et dans les pickers agents.
- Aucun écran ne montre simultanément une liste issue seulement des références et une liste issue des profils persistés comme si elles étaient équivalentes.

View File

@ -0,0 +1,44 @@
---
name: web-client-is-single-column-no-desktop-shell
description: memory note web-client-is-single-column-no-desktop-shell
metadata:
type: project
---
# Le client web n'a pas de shell desktop (ni docks, ni layout grid)
Constat établi en livrant le ticket #69 (adaptibilité téléphone), sur `develop @ 506d589`.
## Le fait
Le client web livré par #13 (`VITE_TRANSPORT=http`) **n'a jamais eu** de docks
gauche/droite, de fenêtres flottantes, de `LayoutTree`, de tabs projet, de menus ni
de toasts. `main.tsx` route `isWeb` vers `WebApp`, qui est une surface autonome :
- `WebApp``PairingScreen` **ou** `WebWorkspace` (rien d'autre) ;
- `WebWorkspace` → une **colonne verticale unique** (`flex flex-col overflow-y-auto`) ;
- `WebAgentCell``TerminalView`.
Les seuls imports `@/features/*` de tout `features/web/` sont `terminals` et
`workstate/useProjectWorkState`. Le shell desktop (`App`, layout, docks) n'est
atteignable que par la branche non-web de `main.tsx`.
## Pourquoi ça compte
Le cadrage de #69 prévoyait un lot « remplacer les docks gauche/droite/floating par
une pile verticale, drawer ou bottom sheet ». Ce lot était **sans objet** : il n'y a
pas de dock à remplacer, et l'arbitrage produit « bottom sheet vs drawer » ne se pose
pas sur cette surface. Le vrai travail téléphone était ailleurs (terminal xterm
pilotable au doigt, `dvh`, safe-area, rangées qui débordent à 360px).
**Avant de cadrer un ticket « responsive / mobile » sur le client web, partir de
`features/web/`, pas du shell desktop.** Les deux surfaces ne partagent que
`TerminalView` et les hooks transport-neutres.
## Garde en place
`frontend/src/features/web/WebMobile.test.tsx` épingle la frontière : le client web
ne doit monter aucun `layout-grid` / `layout-grid-container` / `layout-split` /
`layout-tabs`. Si un jour on veut du desktop-shell dans le web, ce test tombe — et
c'est le signal qu'il faut re-cadrer, pas le supprimer.
Voir aussi [[ui-rework-sprint-scoping-contracts]].

View File

@ -187,6 +187,44 @@
], ],
"fallback": "allow" "fallback": "allow"
} }
},
{
"agentId": "5d07e4a7-8676-4a71-aea1-5b64caefa944",
"permissions": {
"rules": [
{
"capability": "read",
"effect": "allow",
"paths": [
"**"
],
"commands": []
},
{
"capability": "write",
"effect": "deny",
"paths": [
"**"
],
"commands": []
},
{
"capability": "delete",
"effect": "deny",
"paths": [
"**"
],
"commands": []
},
{
"capability": "executeBash",
"effect": "allow",
"paths": [],
"commands": []
}
],
"fallback": "allow"
}
} }
] ]
} }

View File

@ -5,13 +5,8 @@
"id": "a72dac60-641c-4417-b0d7-94b8539f817a", "id": "a72dac60-641c-4417-b0d7-94b8539f817a",
"name": "build-appimage", "name": "build-appimage",
"description": null, "description": null,
"contentHash": "77cb33b978b242f6" "kind": "workflow",
}, "contentHash": "56dd74230ccf517d"
{
"id": "86ea97df-1533-47e5-8809-dc2b02242567",
"name": "mcp-rendezvous-functional-test",
"description": null,
"contentHash": "9fc8260f64c3b9d5"
} }
] ]
} }

View File

@ -0,0 +1 @@
Skill de test

View File

@ -1,6 +1,6 @@
# Build de l'AppImage IdeA (Linux) # Build de l'AppImage IdeA (Linux)
Commande **validée bout-en-bout** (2026-06-17, build exit 0, artefact 106M produit) pour reconstruire l'AppImage Linux d'IdeA. À utiliser à chaque fois qu'un correctif backend/front doit être rendu actif dans l'app (rappel : **le binaire qui tourne = l'AppImage installée, pas les sources** — un correctif n'est actif qu'après rebuild + remplacement + relance d'IdeA). Commande **validée bout-en-bout** (mise à jour 2026-08-03) pour reconstruire l'AppImage Linux d'IdeA. À utiliser à chaque fois qu'un correctif backend/front doit être rendu actif dans l'app (rappel : **le binaire qui tourne = l'AppImage installée, pas les sources** — un correctif n'est actif qu'après rebuild + remplacement + relance d'IdeA).
## Procédure (2 étapes, depuis le project root `/home/anthony/Documents/Projects/IdeA`) ## Procédure (2 étapes, depuis le project root `/home/anthony/Documents/Projects/IdeA`)
@ -12,16 +12,18 @@ npm --prefix frontend run build
### 2. Bundle Tauri AppImage (depuis `crates/app-tauri/`) ### 2. Bundle Tauri AppImage (depuis `crates/app-tauri/`)
```bash ```bash
cd crates/app-tauri cd crates/app-tauri
APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 ../../frontend/node_modules/.bin/tauri build --bundles appimage mkdir -p /tmp/idea-cargo-home
CARGO_HOME=/tmp/idea-cargo-home APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 ../../frontend/node_modules/.bin/tauri build --bundles appimage
``` ```
## Pourquoi ces options (ne pas les retirer) ## Pourquoi ces options (ne pas les retirer)
- `--bundles appimage` : **exclut NSIS** (installeur Windows) — sinutile et cassant sur Linux. - `--bundles appimage` : **exclut NSIS** (installeur Windows) — sinutile et cassant sur Linux.
- `APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1` : **workaround FUSE obligatoire**. Sans ça, l'étape finale `linuxdeploy` (elle-même une AppImage montée via FUSE) échoue avec `failed to run linuxdeploy`. Le compile Rust réussit avant ce point ; seul le bundling casse (l'`AppDir` est généré mais pas le `.AppImage`). - `APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1` : **workaround FUSE obligatoire**. Sans ça, l'étape finale `linuxdeploy` (elle-même une AppImage montée via FUSE) échoue avec `failed to run linuxdeploy`. Le compile Rust réussit avant ce point ; seul le bundling casse (l'`AppDir` est généré mais pas le `.AppImage`).
- `CARGO_HOME=/tmp/idea-cargo-home` : **workaround sandbox/permissions** pour les environnements où `/home/<user>/.cargo` est monté en lecture seule. Sans ça, `tauri build` peut échouer pendant le téléchargement/unpack Cargo avec `Read-only file system (os error 30)`.
## Artefact produit ## Artefact produit
``` ```
target/release/bundle/appimage/IdeA_0.1.0_amd64.AppImage target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
``` ```
(Le build est long : compile Rust release ~1 min + bundling. Lancer en arrière-plan.) (Le build est long : compile Rust release ~1 min + bundling. Lancer en arrière-plan.)
@ -29,4 +31,4 @@ target/release/bundle/appimage/IdeA_0.1.0_amd64.AppImage
Pour rendre le correctif actif, il faut **remplacer l'AppImage installée** `/home/anthony/Documents/IdeA_0.1.0_amd64.AppImage` par l'artefact, puis **relancer IdeA**. ⚠️ Relancer IdeA **tue l'orchestrateur en cours** (le serveur qui héberge la session active et les ponts MCP) : à faire par l'utilisateur quand il est prêt, pas en pleine session multi-agents. Garder un backup de l'ancienne AppImage avant remplacement (cf. convention `.old-<raison>`). Pour rendre le correctif actif, il faut **remplacer l'AppImage installée** `/home/anthony/Documents/IdeA_0.1.0_amd64.AppImage` par l'artefact, puis **relancer IdeA**. ⚠️ Relancer IdeA **tue l'orchestrateur en cours** (le serveur qui héberge la session active et les ponts MCP) : à faire par l'utilisateur quand il est prêt, pas en pleine session multi-agents. Garder un backup de l'ancienne AppImage avant remplacement (cf. convention `.old-<raison>`).
## Piège env (si on lance un binaire ensuite) ## Piège env (si on lance un binaire ensuite)
La session shell hérite des variables de l'AppImage montée (`APPDIR`, `LD_LIBRARY_PATH`, `PYTHONHOME``/tmp/.mount_IdeA_*`). Pour lancer un binaire app-tauri compilé sans crash WebKit, partir d'un env propre (`env -i PATH=/usr/bin:/bin HOME=$HOME XDG_RUNTIME_DIR=/run/user/1000 …`) et préférer `jq` à `python3`. La session shell hérite des variables de l'AppImage montée (`APPDIR`, `LD_LIBRARY_PATH`, `PYTHONHOME``/tmp/.mount_IdeA_*`). Pour lancer un binaire app-tauri compilé sans crash WebKit, partir d'un env propre (`env -i PATH=/usr/bin:/bin HOME=$HOME XDG_RUNTIME_DIR=/run/user/1000 …`) et préférer `jq` à `python3`.

View File

@ -0,0 +1,111 @@
# Build de l'AppImage IdeA (Linux)
Procédure canonique pour reconstruire l'AppImage Linux d'IdeA et les bundles frontend associés.
À utiliser à chaque fois qu'un correctif doit être visible dans l'app desktop. Rappel produit : **le binaire qui tourne = l'AppImage installée, pas les sources**. Un correctif source n'est actif dans l'app desktop qu'après rebuild, remplacement de l'AppImage utilisée, puis relance d'IdeA.
## Commande principale
Depuis le project root `/home/anthony/Documents/Projects/IdeA` :
```bash
cd crates/app-tauri
APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=true ../../frontend/node_modules/.bin/tauri build --bundles appimage
```
Cette commande déclenche `build.beforeBuildCommand`, donc elle reconstruit automatiquement les deux bundles frontend :
- `frontend/dist` : bundle desktop, transport `tauri`.
- `frontend/dist-web` : bundle web, transport `http`.
Ne pas revenir à l'ancienne procédure `npm --prefix frontend run build` seule : elle ne reconstruit pas le bundle web séparé.
## Vérification des bundles web/desktop
Après le build, lancer :
```bash
npm --prefix frontend run test:bundle-transport
```
Sortie attendue :
```text
dist: __IDEA_TRANSPORT__="tauri" (1 marker)
dist-web: __IDEA_TRANSPORT__="http" (1 marker)
```
## Artefact attendu
```text
target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
```
Vérifier rapidement :
```bash
ls -lh target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
APPIMAGE_EXTRACT_AND_RUN=1 target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage --appimage-help | head
```
## Pourquoi ces variables sont obligatoires
- `--bundles appimage` : cible uniquement l'AppImage Linux et évite les bundles inutiles/cassants comme NSIS.
- `NO_STRIP=true` : évite l'échec linuxdeploy/strip sur les bibliothèques système modernes contenant `.relr.dyn`.
- `APPIMAGE_EXTRACT_AND_RUN=1` : évite l'échec FUSE quand linuxdeploy ou appimagetool ne peuvent pas monter une AppImage dans l'environnement courant.
## Fallback si Tauri échoue à `failed to run linuxdeploy`
Symptôme : la commande Tauri reconstruit `frontend/dist`, `frontend/dist-web`, compile `target/release/app-tauri`, crée `target/release/bundle/appimage/IdeA.AppDir`, puis échoue seulement à l'étape finale :
```text
failed to bundle project `failed to run linuxdeploy`
```
Ne pas réanalyser tout le build. Faire ce diagnostic court :
```bash
APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=true LDAI_OUTPUT=/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage \
/home/anthony/.cache/tauri/linuxdeploy-x86_64.AppImage \
--appdir /home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA.AppDir \
--output appimage
```
Si `appimagetool` échoue avec téléchargement runtime impossible :
```text
Failed to download runtime file
```
utiliser le runtime local déjà en cache et l'`appimagetool` extrait. Chercher le dossier extrait récent :
```bash
find /tmp -path '*/appimagetool-prefix/usr/bin/appimagetool' -type f -printf '%p\n' | tail -1
```
Puis lancer en remplaçant `<EXTRACTED>` par le préfixe trouvé, par exemple `/tmp/appimage_extracted_xxx` :
```bash
PATH=<EXTRACTED>/appimagetool-prefix/usr/bin:$PATH \
ARCH=x86_64 \
<EXTRACTED>/appimagetool-prefix/usr/bin/appimagetool \
--runtime-file /home/anthony/.cache/tauri/runtime-x86_64 \
/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA.AppDir \
/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
```
Le `PATH` est nécessaire parce que `mksquashfs` est fourni dans `appimagetool-prefix/usr/bin` et peut être absent du PATH système.
## Relance de l'application
Ne pas relancer IdeA automatiquement depuis une session active : cela tue l'orchestrateur courant et les ponts MCP. Une fois l'AppImage reconstruite, l'utilisateur décide quand remplacer/lancer l'artefact final.
## Piège d'environnement AppImage
Une session shell lancée depuis l'AppImage peut hériter de variables comme `APPDIR`, `LD_LIBRARY_PATH`, `PYTHONHOME` pointant vers `/tmp/.mount_IdeA_*`. Symptômes possibles : `python3` casse avec `No module named 'encodings'`, ou un binaire Tauri local se lance dans un environnement pollué.
Pour des commandes sensibles, préférer un environnement propre ou éviter Python :
```bash
env -i PATH=/usr/bin:/bin HOME=$HOME XDG_RUNTIME_DIR=/run/user/1000 <commande>
```

View File

@ -0,0 +1,11 @@
---
id: "e28a4d53-8bd2-446a-b0ac-2a017373b8b2"
order: 5
name: "Gestion des bugs"
status: "planned"
createdBy: {"kind":"user"}
updatedBy: {"kind":"user"}
createdAt: 1783923775150
updatedAt: 1783923775150
version: 1
---

View File

@ -36,6 +36,15 @@
"status": "planned", "status": "planned",
"updatedAt": 1783757205620, "updatedAt": 1783757205620,
"version": 2 "version": 2
},
{
"id": "e28a4d53-8bd2-446a-b0ac-2a017373b8b2",
"path": "e28a4d53-8bd2-446a-b0ac-2a017373b8b2",
"order": 5,
"name": "Gestion des bugs",
"status": "planned",
"updatedAt": 1783923775150,
"version": 1
} }
] ]
} }

View File

@ -0,0 +1,6 @@
{
"version": 1,
"projectDefault": {
"network": "allow"
}
}

View File

@ -0,0 +1,6 @@
---
issueRef: "#100"
version: 3
updatedBy: {"kind":"user"}
updatedAt: 1784993984569
---

View File

@ -0,0 +1,16 @@
---
id: "4709958c-5082-44fd-a1fd-d6bad85f9361"
number: 100
title: "[Bug] Problème sur le scroll des agents OpenCode"
status: "closed"
priority: "high"
sprint: "e28a4d53-8bd2-446a-b0ac-2a017373b8b2"
links: []
agentRefs: []
createdBy: {"kind":"user"}
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
createdAt: 1784992615586
updatedAt: 1785083912470
version: 4
---
Quand un agent est un agent opencode, je ne peux aps scroll très haut dans sa cellule.

View File

@ -0,0 +1,96 @@
---
issueRef: "#101"
version: 7
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
updatedAt: 1785011116365
---
# Carnet #101 — défaut d'isolation multi-projet (cause racine figée)
> Diagnostic Architect (2026-07-25). Source de vérité du fix. Mémoire durable :
> `ticket101-cross-talk-multi-project-rootcause`.
## Cause racine
Stores disque IdeA **correctement scoppés par projet** (mémoire, contexte, handoff, live-state lus
depuis `input.project.root` ; agents persistés dans `.ideai/agents.json` par root projet, **sans
re-mint des UUID à l'ouverture**). Mais plusieurs **registres mémoire runtime restent globaux,
indexés par `AgentId` seul** → deux projets ouverts (surtout si l'un est une copie) peuvent porter
les **mêmes `AgentId`** et le runtime les confond.
### 2 manifestations, même défaut
- **A — contamination du contexte d'inférence** : conversation/session d'un projet réutilisée pour
l'autre → contexte injecté à l'agent contaminé (preuve : pseudo-branche `wear-os-watch-sync`
créée par l'agent Git avec un nom de l'autre projet).
- **B — notification de tâche backend perdue / agent s'arrête** (sujet original) : complétion
livrable/bloquée/réveillant la mauvaise session.
## Points précis (registres par `AgentId` seul à requalifier)
- ConversationRegistry global + `ConversationId` dérivé des UUID agents seuls :
`crates/domain/src/conversation.rs:71`, `crates/infrastructure/src/conversation/mod.rs:41`,
orchestrateur `crates/application/src/orchestrator/service.rs:2192` (et `:2293`, `:2368`).
- Sessions PTY/structured par `agent_id` seul :
`crates/application/src/terminal/registry.rs:182,437`.
- Verrous ask / busy-state / liveness / délégations différées :
`crates/application/src/orchestrator/service.rs:418`,
`crates/infrastructure/src/input/mod.rs:47`.
- Inbox/mailbox par `AgentId` seul : `crates/domain/src/inbox.rs:68,156`,
`crates/infrastructure/src/input/mod.rs:1052`, `crates/infrastructure/src/mailbox/mod.rs:44`.
- Wake par `AgentId` seul : `crates/application/src/orchestrator/wake.rs:87`,
provider `crates/backend/src/lib.rs:687`.
### Pour B — distinction runtime vs modèle
La chaîne sink→`project_id`→wake est **correcte** jusqu'au bridge
(`crates/infrastructure/src/background_task/sink.rs:23,142` ; `crates/backend/src/lib.rs:2228`
recharge le projet par `project_id` puis `wake_agent`). Le défaut réapparaît juste après
(inbox/mailbox/busy/session par AgentId seul). **Runtime IdeA suspecté en premier.** GLM 5.2 n'est
l'hypothèse principale que si les logs prouvent enqueue+wake+`BackgroundTaskCompletionDelivered`
sur le bon projet sans reprise. Traces : `lib.rs:2238`, `wake.rs:93`.
## Décision utilisateur
**Lancer le fix structurel maintenant (lots 1-2).** La collision d'UUID et les logs B se
vérifieront en parallèle.
## Périmètre DevBackend (lots 1-2 de ce fix)
- **Lot 1** : introduire une clé runtime scellée `RuntimeAgentKey { project_id, agent_id }` ;
interdire toute map app-wide indexée par `AgentId` seul.
- **Lot 2** : propager la clé dans `AgentInbox`, `InputMediator`, `AgentMailbox`,
busy/liveness/deferred, wake, session lookup, ask-locks. **Correctif structurel commun à A et B.**
Lots suivants (3-6, hors premier passage) : qualifier ConversationId/registry par projet (lot 3) ;
requalifier `TerminalSessions`/`StructuredSessions` par `(project_id, agent_id)` +
`AppWakeSessionProvider` refuse l'autre projet (lot 4) ; audit `session_limit`/tables reprise (lot 5) ;
télémétrie `project_id` sur logs diag wake/routage (lot 6).
## Invariants
- Sources de contexte sur disque restent root-scopées (ne pas régresser).
- Templates/profils globaux restent globaux produit (pas de vecteur de session/conversation partagée).
- Un projet non-actif doit continuer à recevoir ses wakes et complétions.
- Pas de régression OpenCode/Codex/Claude (correctif transverse runtime, pas moteur-spécifique).
- Aucun nouveau DTO frontend pour la correction minimale.
## QA — critère de vérité
Test d'intégration **non-cross-talk** : 2 projets ouverts avec **volontairement les mêmes `AgentId`** :
- délégation projet A ne réutilise jamais session/conversation vivante de projet B ;
- complétion `(projet A, agent X)` n'entre ni dans l'inbox ni dans la session de `(projet B, agent X)` ;
- wake d'un projet non-actif fonctionne ;
- collision d'ids qui échouait avant → verte sur PTY, structured et background wake.
## Clôture 2026-07-25
- Correctif livré sur `feature/ticket101-multi-project-isolation` puis mergé localement dans `develop`.
- Commit feature : `6e98fd8 fix(runtime): isolate agent state by project (#101)`.
- Merge local : `merge: integrate ticket 101 multi-project isolation`.
- QA ciblée verte :
- `cargo test -p application --test agent_wake --test orchestrator_service --test structured_registry_d1 --test structured_launch_d3 --test session_limit_service --test session_limit_t4 --test workstate --test workstate_actions`
- `cargo test -p infrastructure --test agent_inbox --test mcp_server`
- `cargo test -p app-tauri --test session_limit_wiring`
- `cargo test -p application`
- `cargo test -p app-tauri --tests`
- Réserve connue : `cargo test -p infrastructure` complet reste rouge dans le sandbox QA sur tests `openai_compat` à cause du bind local interdit (`Operation not permitted`), sans signal de régression #101.
## Hors périmètre
- #91 (popup de notification) : purement front, indépendant.
- Remint systématique des AgentId à l'ouverture : non retenu (la clé runtime rend la collision
inoffensive même sans remint).
## Lié
- #91 (relatesTo). Mémoires : `background-tasks-first-class-design`, `b8-command-runner-pty-framing`,
`mcp-bridge-and-delegation-runtime-notes` (règle rebuild AppImage).

View File

@ -0,0 +1,16 @@
---
id: "05f9f05b-97d4-4ae2-9fd9-220dd71f7231"
number: 101
title: "[Bug] Soucis de retour de notification sur les taches backend"
status: "closed"
priority: "critical"
sprint: "e28a4d53-8bd2-446a-b0ac-2a017373b8b2"
links: []
agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
createdBy: {"kind":"user"}
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
createdAt: 1784993230013
updatedAt: 1785011116365
version: 7
---
Lorsque un agent Opencode lance une tache backend, il s'arrete de travailler et je ne suis pas sur q'uil y ai un jour un retour de notification. Je ne sais aps si le soucis provient de OpenCode ou s'il provient du model (GLM 5.2 ici)

View File

@ -0,0 +1,38 @@
---
issueRef: "#102"
version: 11
updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
updatedAt: 1785878554632
---
## 2026-08-04 — Réouverture
- Repro utilisateur confirmée: en changeant de projet, si une cellule contient un terminal d'agent IA et que du contenu est arrivé pendant que le projet n'était pas affiché, le terminal revient partiellement/blanc/tronqué.
- Symptôme visuel observé: le contenu complet réapparaît immédiatement après un resize de la cellule ou de la fenêtre.
- Portée repro indiquée historiquement: switch de projet, switch de layout, ajout/suppression/redécoupage de cellules; le cas prioritaire confirmé aujourd'hui est le retour sur projet.
- Hypothèse de travail à valider: problème de refresh/fit/reflow frontend du terminal lors de la ré-attache ou ré-activation de la vue, pas un manque de données côté agent.
- Action en cours: recadrage Architect, décision de branche Git, implémentation dev ciblée, puis validation QA sur reproduction réelle.
## 2026-08-04 — Cadrage Architecture (analyse statique, avant implémentation)
- Frontière validée: frontend pur, ciblée sur `frontend/src/features/terminals/TerminalView.tsx`.
- Le backend/PTY n'est pas suspecté à ce stade: le tail de scrollback est bien restitué au reattach; le défaut semble être de rendu/reflow au retour sur la vue.
- Point d'attention principal: `term.write(scrollback)` pourrait arriver avant le premier `fit()` réellement utile, ce qui laisserait xterm wrapper le contenu sur une géométrie transitoire et n'obtiendrait un repaint correct qu'au resize manuel ultérieur.
- Les correctifs précédents ont déjà renforcé la boucle de fit; le trou probable est l'absence de test sur le rendu/repaint effectif et sur l'ordre `reattach/write` vs `first useful fit`.
- Stratégie recommandée: corriger dans `TerminalView` l'ordre de réécriture du scrollback et/ou forcer un repaint plein-buffer après le premier fit utile, puis valider par test ciblé et repro réelle.
## 2026-08-04 — Implémentation DevFrontend
- Correctif appliqué dans `frontend/src/features/terminals/TerminalView.tsx`.
- Changement clé: en cas de `reattach`, le scrollback et les chunks live reçus pendant la fenêtre de réattache ne sont plus écrits immédiatement dans xterm; ils sont tamponnés jusqu'au premier `fit` utile, puis rejoués dans l'ordre `scrollback` puis `live output`.
- Objectif: éviter un rendu initial du buffer sur une géométrie transitoire et supprimer la dépendance à un resize manuel ultérieur pour déclencher l'affichage correct.
- Test ajouté/ajusté dans `frontend/src/features/terminals/TerminalView.test.tsx` pour verrouiller qu'aucun `term.write` ne précède le premier `fit` utile et que l'ordre de replay est conservé.
## 2026-08-04 — Verdict QA
- Validation automatisée verte:
- `cd frontend && npx vitest run src/features/terminals/TerminalView.test.tsx` -> 22 tests passés.
- `cd frontend && npx vitest run src/features/terminals/TerminalView.scrollback.test.tsx src/features/terminals/TerminalView.portal.test.tsx` -> 5 tests passés.
- `cd frontend && npx vitest run src/features/terminals` -> 39 tests passés.
- `cd frontend && npx vitest run` -> 115 fichiers, 1083 tests passés.
- Verdict QA: `vert avec réserve de preuve manuelle`.
- Réserve restante: absence de repro visuelle réelle rejouée dans l'application avec un vrai xterm, une session vivante, puis un reattach après switch projet/layout. Le ticket reste donc ouvert tant que cette validation de terrain n'est pas obtenue.

View File

@ -0,0 +1,17 @@
---
id: "e91fd358-da94-4382-aa70-6a3fe5a63840"
number: 102
title: "[Bug] Devoir resize les cellule pour afficher la TUI d'un agent"
status: "inProgress"
priority: "medium"
sprint: "e28a4d53-8bd2-446a-b0ac-2a017373b8b2"
links: []
agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
attachments: []
createdBy: {"kind":"user"}
updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
createdAt: 1784993319700
updatedAt: 1785878554632
version: 11
---
J'ai toujours un soucis qui fait que quand je switch de projet IdeA ou de layout ou que j'ajoute des cellules ou autres, je suis obligé de resize un coup la cellule pour que son constenu s'affiche correctement

View File

@ -0,0 +1,99 @@
---
issueRef: "#103"
version: 5
updatedBy: {"kind":"user"}
updatedAt: 1785271085635
---
# Carnet #103 — permission réseau exposée dans IdeA
## Problème
Certaines commandes lancées par les agents s'exécutent dans un environnement où le réseau est restreint, sans visibilité ni action claire dans IdeA. Exemple live : rebuild AppImage OK jusqu'au bundling, puis `appimagetool` échoue à télécharger le runtime GitHub car la session agent est `network restricted` + `approval policy: never`.
## Décision UX
Mémoire : `ticket103-network-permission-ux-surface`.
- Surface principale : `Permissions > Système`.
- Miroirs de lecture : badge compact dans `Agents`, bannière/erreur contextualisée dans `Terminal`.
- États visibles : `Réseau autorisé`, `Réseau interdit`, `Demande d'autorisation`, `Verrouillé par le runtime`.
- Distinction obligatoire : politique voulue, état effectif, verrou runtime.
- Si le runtime externe ne permet pas l'élévation dans la session active : contrôle read-only + explication explicite.
## Cadrage architecture
Ne pas étendre le modèle existant `ProjectPermissions` fichier/bash : le réseau n'est ni une capability filesystem ni une règle Landlock. Ajouter un modèle/read-model séparé de permissions système.
### Domaine / DTO V1
- `NetworkPolicy = "allow" | "deny" | "ask"`.
- `SystemPermissionSet { network?: NetworkPolicy }`.
- `ProjectSystemPermissions { version, projectDefault?: SystemPermissionSet, agents?: [{ agentId, permissions: SystemPermissionSet }] }`.
- `ResolvedAgentSystemPermissions` :
- `wanted: NetworkPolicy | null`
- `effective: NetworkPolicy`
- `runtimeLock: { state: "none" | "locked", source?: string, reason?: string }`
- `control: { mode: "editable" | "readOnly", reason?: string }`
### Ports / use cases
- `SystemPermissionStore`.
- `GetProjectSystemPermissions`.
- `UpdateProjectSystemPermissions`.
- `UpdateAgentSystemPermissions`.
- `ResolveAgentSystemPermissions`.
- `RuntimePermissionProbe` : expose ce que le runtime hôte/fournisseur autorise réellement et s'il verrouille le réseau.
### API/commands attendus
- `get_project_system_permissions(projectId) -> ProjectSystemPermissionsDto`
- `update_project_system_permissions({ projectId, permissions }) -> ProjectSystemPermissionsDto`
- `update_agent_system_permissions({ projectId, agentId, permissions }) -> ProjectSystemPermissionsDto`
- `resolve_agent_system_permissions({ projectId, agentId }) -> ResolvedAgentSystemPermissionsDto`
### Limite produit V1
Implémentable maintenant : persister la politique voulue, afficher `wanted/effective/runtimeLock`, rendre le contrôle read-only si runtime verrouillé/non inspectable, badges agents, bannière terminal.
Non promis en V1 : changer effectivement la permission réseau d'une session fournisseur déjà lancée ou élever un runtime externe `network restricted` / `approval never`. IdeA doit l'expliquer plutôt que simuler une élévation.
## Découpage
### DevBackend
1. Ajouter domaine `system permissions` séparé de LP1 permissions fichier/bash.
2. Ajouter store + use cases + DTO + commands Tauri/HTTP.
3. Ajouter `RuntimePermissionProbe` read-only au composition root.
4. Ajouter read-model `resolve_agent_system_permissions`.
5. Optionnel si simple : mapper des échecs réseau vers un code stable `NETWORK_LOCKED` ou `NETWORK_UNAVAILABLE`.
### DevFrontend
1. Étendre types domaine, ports, adapters Tauri/HTTP/mock.
2. Ajouter la sous-section `Réseau` dans `Permissions > Système`.
3. Ajouter badge compact dans `Agents`.
4. Ajouter bannière/erreur terminal contextualisée pour état verrouillé/échec réseau.
### QA
- Projet sans config : état cohérent, pas de faux `allow`.
- Save project default puis override agent : relecture identique.
- Resolve distingue `wanted`, `effective`, `runtimeLock`.
- Probe `locked` : contrôle read-only + message visible.
- Non-régression `Permissions > Système` existant fichier/bash.
- Aucun moteur ne reçoit de faux flag réseau au spawn.
- Badge agents et bannière terminal reflètent l'état effectif.
## Validation 2026-07-25
QA verte sur le périmètre #103.
Commandes exécutées par QA :
- `cargo test -p domain system_permissions`
- `cargo test -p application --test system_permission_usecases`
- `cargo test -p infrastructure --test system_permission_store`
- `cargo test -p app-tauri --test dto_system_permissions`
- `cargo test -p web-server allowlisted`
- `npm run typecheck`
- `npx vitest run src/features/permissions/permissions.test.tsx src/features/agents/agents.test.tsx src/features/terminals/TerminalView.test.tsx`
- `npx vitest run src/features/permissions/permissions.test.tsx`
Résultats : backend ciblé vert, frontend typecheck vert, tests frontend ciblés 49 passed.
## État Git
Implémentation validée dans le working tree courant, mais commit/merge non réalisé par Main :
- l'agent Git headless renvoie un pseudo-appel outil au lieu d'agir ;
- Main ne peut pas écrire `.git/index.lock` depuis cette session (`Read-only file system`).
Le commit local reste à faire manuellement ou via un agent Git fonctionnel.
## Critère de clôture
Tests pertinents verts, commit/merge local par Git, puis rebuild AppImage.

View File

@ -0,0 +1,39 @@
---
id: "3d9021da-26c3-439d-9463-8d206bd06f1b"
number: 103
title: "Exposer et piloter la permission réseau des agents/commandes dans IdeA"
status: "closed"
priority: "high"
sprint: null
links: []
agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
updatedBy: {"kind":"user"}
createdAt: 1785011668081
updatedAt: 1785271085635
version: 5
---
## Problème
Aujourd'hui certaines commandes lancées par les agents s'exécutent dans un environnement où le réseau est restreint, sans que l'utilisateur puisse le voir ni l'autoriser depuis IdeA. Exemple réel : rebuild AppImage OK jusqu'au bundling, puis `appimagetool` échoue à télécharger le runtime AppImage depuis GitHub (`Failed to download runtime: server returned status code 0`) parce que la session agent a `network restricted` et `approval policy: never`.
## Besoin utilisateur
Depuis IdeA, l'utilisateur doit pouvoir comprendre et piloter cette permission réseau :
- voir qu'un agent/profil/session est en mode réseau interdit ou autorisé ;
- configurer la politique réseau attendue pour les agents/commandes ;
- éviter les échecs opaques de commandes qui ont légitimement besoin d'Internet (build, install, téléchargement runtime, docs, dépendances) ;
- conserver un comportement sûr par défaut et explicite.
## Attendu produit
Définir puis implémenter une surface IdeA pour exposer cette permission. La solution doit respecter le modèle de permissions/sandbox existant et clarifier la limite éventuelle : si le sandbox fournisseur impose `network restricted` sans possibilité d'élévation runtime, IdeA doit l'expliquer plutôt que faire croire que le réseau est activable.
## Critères d'acceptation
- Une surface UI ou configuration explicite permet de voir la politique réseau applicable aux agents/commandes.
- L'utilisateur dispose d'une action ou d'un réglage clair quand IdeA peut piloter cette permission.
- Si la permission est imposée par le runtime externe et non modifiable, l'UI l'indique clairement.
- Les agents/commandes ne gagnent pas l'accès réseau silencieusement.
- Tests pertinents verts.
- AppImage reconstruite après livraison.

View File

@ -0,0 +1,6 @@
---
issueRef: "#107"
version: 4
updatedBy: {"kind":"user"}
updatedAt: 1785271098557
---

View File

@ -0,0 +1,17 @@
---
id: "6a79006b-0201-4176-ae54-39a05cc3baa6"
number: 107
title: "[Bug] croisement entre les projet des retours des agents"
status: "closed"
priority: "critical"
sprint: null
links: []
agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
createdBy: {"kind":"user"}
updatedBy: {"kind":"user"}
createdAt: 1785136727824
updatedAt: 1785271098557
version: 4
---
Il y a un soucis très important que j'ai constatés. J'ai actuellement 2 projets ouverts: IdeA et GameTime. Les deux projets travaillaient en même temps et j'ai vu GameTime qui semblait récupérer une requete du projet IdeA. Pour plus de précision, sur mes deux projets, j'ai un agent Git qui utilise OpenCode et un modelle local llamacpp, et j'ia eu l'impression qu'ils ont tous les deux appelé leur agent Git mais GameTime à recus la réponse de IdeA car la réponse parlait d'une branche du projet IdeA.
Je ne suis pas totalement sur de ce que j'avance, la seule chose dont je suis sur, c'est que GameTime s'est vu adressé une réponse qui était déstinée au projet IdeA.

View File

@ -0,0 +1,6 @@
---
issueRef: "#108"
version: 3
updatedBy: {"kind":"user"}
updatedAt: 1785328001206
---

Some files were not shown because too many files have changed in this diff Show More