184 Commits

Author SHA1 Message Date
805d4b70a2 Merge feature/model-server-hf-source-wizard-v2 into develop
Support natif d'une source modèle Hugging Face (-hf) en alternative au
chemin .gguf local pour le serveur llama.cpp intégré, options structurées
llama.cpp (host/gpu_layers/context_size/jinja), preview de commande, et
refonte UX du wizard V2. Migration store model-servers.json V1 -> V2.

QA : suites ciblées vertes (domain 7, application 8, infra model_server 4,
app-tauri dto 5, Vitest 22, tsc/build OK).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-12 14:32:21 +02:00
efa081b074 feat(model-server): wizard V2 config modèles locaux — source, options structurées & preview
Refonte UX du wizard de configuration des modèles locaux du serveur
llama.cpp intégré, alignée sur la source Hugging Face et les options backend.

- choix de source sans jargon (chemin local .gguf vs dépôt Hugging Face) ;
- champs structurés -ngl (gpu_layers), -c (context_size), --jinja, --host ;
- zone d'arguments libres avec alerte sur les flags réservés ;
- preview de la commande via le backend (previewModelServerCommand, debounced) ;
- gateway/ports et mock adaptés au contrat V2.

QA : Vitest 22 verts, tsc/build OK.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-12 14:32:04 +02:00
38aecf2cac feat(model-server): source Hugging Face (-hf) + options structurées llama.cpp + migration store V2
Backend du support natif d'une source modèle Hugging Face en alternative au
chemin .gguf local pour le serveur llama.cpp intégré, et refonte des options.

- domaine : ModelSource {LocalPath|HuggingFace} + HfModelRef,
  LlamaCppOptions {host,gpu_layers,context_size,jinja}, invariant auto_start
  exigeant une source, validate_free_args (rejet des flags réservés).
- infra : build_argv partagé avec build_spawn_spec, émission -hf vs --model,
  ordre argv figé ; migration model-servers.json V1 -> V2.
- app-tauri : DTO V2 (modelSource, compat modelPath, conflit = INVALID),
  commande preview_model_server_command.

QA : cargo test ciblés verts (domain 7, application 8, infra model_server 4,
app-tauri dto 5). Échecs des suites complètes infra/app-tauri environnementaux
(sandbox bind/socket), hors périmètre.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-12 14:31:54 +02:00
bc96285fa5 Merge feature/modeles-locaux into develop
Sprint « Modeles locaux » terminé et vert : serveur de modèle local
llama.cpp intégré (#35) et profils OpenCode locaux multiples (#36).
Backend (domain/application/infra/app-tauri) + frontend.

Tests verts (exécution réelle) : cargo build workspace Finished ;
domain+application ; app-tauri dto_model_servers 3/3, dto_profiles 10/10 ;
infra model_server 2/2 ; application model_server+profile_usecases 19/19 ;
frontend tsc propre + vitest 608/608.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-11 15:51:05 +02:00
a244f32f31 chore(ideai): versionne le store tickets/sprints/mémoire du sprint Modeles locaux
Store d'orchestration du sprint « Modeles locaux » : sprint 883534aa,
tickets #35/#36 (et #32/#37–#41 du store), compteurs et index, notes
mémoire de livraison (#35 CRUD/statut, #36 multi-profils, OpenCode↔llama.cpp).

Runtime transitoire volontairement exclu (background-tasks/, agent scratch
testllamacpp.md).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-11 15:50:46 +02:00
72476a650a feat(model-server): frontend modèles locaux — badge de statut & CRUD serveurs (#35) et wizard multi-profils OpenCode (#36)
Sprint « Modeles locaux », couche frontend.

#35 :
- F35.1 badge de statut de lancement du serveur local
  (ModelServerLaunchBadge + useAgentsModelServer).
- F35.2 feature model-servers : CRUD (ModelServersPanel / useModelServers /
  gateway modelServer) et ModelServerSelect.

#36 :
- Liste multi-profils OpenCode dans le wizard de premier lancement,
  gateway de clonage (clone_opencode_profile_from_seed).

Tests verts (exécution réelle) : tsc propre, vitest 608/608.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-11 15:50:18 +02:00
b82ac76f8b feat(model-server): backend modèles locaux — serveur llama.cpp intégré (#35) et profils OpenCode locaux multiples (#36)
Sprint « Modeles locaux », couche backend (domain/application/infra/app-tauri).

#35 — Serveur de modèle local intégré (llama.cpp) :
- domain: model_server.rs (agrégat + statut), ports ModelServerProbe /
  ManagedProcess / ModelServerRuntime / ModelServerRegistry, événements
  model_server_status_changed et agent_launch_failed.
- application: use case EnsureLocalModelServer branché sur LaunchAgent.
- infrastructure: adapters HttpOpenAiCompatibleProbe, LlamaCppRuntime,
  LocalManagedProcess, FsModelServerRegistry.
- app-tauri: DTO plat LocalModelServerConfigDto, commandes
  list/save/delete_model_server avec garde model_server_in_use, wiring.

#36 — Profils OpenCode locaux multiples :
- domain: VO LocalModelServerId, OpenCodeConfig.local_model_server_id.
- application: use case CloneOpenCodeProfileFromSeed.
- app-tauri: commande clone_opencode_profile_from_seed, DTO/wiring.

Tests verts (exécution réelle) : domain+application OK, app-tauri
dto_model_servers 3/3 et dto_profiles 10/10, infra model_server 2/2,
application model_server+profile_usecases 19/19, cargo build workspace Finished.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-11 15:50:08 +02:00
2e98f1fbb9 Merge feature/opencode-llamacpp into develop
Remplace le provider Ollama par llama.cpp dans l'intégration OpenCode
(tool-calling local). QA vert, réserve E2E live non bloquante.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-11 00:41:31 +02:00
4e70631c40 feat(opencode): remplace le provider Ollama par llama.cpp
Le tool-calling local ne fonctionnait jamais via Ollama. Refonte du
support local d'OpenCode autour de llama.cpp: profil, catalogue,
matérialisation de la config OpenCode et surface first-run alignés sur
llama-server (backend + frontend).

QA vert (commandes réelles): domain 244, application 81+64, infra 263
(10 échecs = bind-port sandbox identiques sur develop, non-régression),
frontend 574, tsc propre. Réserve E2E live non bloquante faute de
llama-server joignable.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-11 00:41:19 +02:00
eaba05d27d feat(opencode): remplace le profil Ollama HTTP par OpenCode
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-09 15:48:07 +02:00
2fa226e413 chore(tickets): versionne le store de tickets et de sprints du projet
`.ideai/tickets/` et `.ideai/sprints/` sont le registre durable du projet (les
tickets sont déjà référencés par les messages de commit : #14, #21..#25, #28),
au même titre que `.ideai/memory/`. Ils entrent donc dans le dépôt.

À l'inverse, `.ideai/background-tasks/` (snapshots de rendez-vous headless) et
`.ideai/proposals/` (amendements de contexte en attente d'arbitrage) restent de
l'état d'exécution transitoire, de la même classe que `live-state.json` et
`.ideai/requests/` : ils doivent être ignorés (patch `.gitignore` à venir).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-08 08:38:33 +02:00
56757c7e1b chore(ideai): contextes des agents UX/TestOllama, MAJ DevFrontend et permissions associées
Ajoute les contextes des deux nouveaux agents et enregistre leurs règles dans
`.ideai/permissions.json`. Aucun impact applicatif : état de configuration
projet, isolé du code de feature.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-08 08:38:21 +02:00
ffc458e477 docs(memory): notes projet du sprint UI rework et des tickets #7/#14/#16/#17/#18/#25/#28
Capitalise les notes durables produites pendant le sprint UI rework et les
tickets livrés depuis. Commit séparé du code : `.ideai/memory/` est le store
durable versionné, il ne doit jamais être mélangé aux commits de feature.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-08 08:38:16 +02:00
710fa8fdd7 Merge feature/ticket28-firstrun-detect-hang into develop (#28)
First-run wizard figé : boutons « Save and continue » et « Detect installed
CLIs » grisés à vie.

Cause racine à deux étages, corrigée aux deux :
- backend : `AgentRuntime::detect` était un `fn` synchrone pilotant un
  spawner async via un `block_on` imbriqué — panique sous le runtime Tauri,
  commande IPC sans réponse. Le port passe en `async fn`, la sonde est bornée
  par un timeout, et les profils OpenAI-compatible sont sondés en HTTP.
- frontend : `busy` awaitait `detectProfiles`, si bien qu'une promesse
  pendante grisait les actions sans issue. La détection devient best-effort,
  suivie par un drapeau `detecting` séparé qui n'inhibe rien.

QA vert (exécution réelle) : domain 241, application 81, infrastructure 269,
app-tauri 63+15 ; vitest 569 tests / 59 fichiers ; tsc --noEmit exit 0.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-08 08:12:00 +02:00
0389e2e0b0 fix(first-run): découple busy de la détection des CLI (#28)
Même backend réparé, le wizard restait à la merci d'une détection qui ne
répond pas : `reload()` et `detect()` awaitaient `detectProfiles` sous le
même drapeau `busy` qui grise « Save and continue » et « Detect installed
CLIs ». Une promesse IPC jamais résolue laissait donc les deux boutons
grisés à vie — sans issue pour l'utilisateur.

La détection redevient ce qu'elle est : une étape best-effort, jamais
bloquante.

- `busy` ne garde plus que ce dont le wizard ne peut pas se passer
  (`firstRunState`) ou qui mute l'état (`configureProfiles`). Il ne dépend
  plus jamais de `detectProfiles`. L'invariant est documenté en tête de
  module.
- Un drapeau `detecting` distinct suit la sonde et n'inhibe aucune action.
  Il est relâché par un timer (`DETECT_TIMEOUT_MS`), jamais par la seule
  promesse : celle-ci peut rester pendante indéfiniment.
- Un identifiant de tour monotone (`detectRun`) invalide les tours périmés
  et ceux qui survivent au démontage, évitant un `setState` hors montage.
- `reload()` rend les lignes immédiatement puis lance la détection en tâche
  détachée. Si elle échoue, les lignes restent cochables à la main ; seul le
  bouton explicite remonte l'erreur.

Tests: vitest 59 fichiers / 569 tests verts, tsc --noEmit exit 0.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-08 08:11:24 +02:00
3abf2fce98 fix(runtime): detection non bloquante, bornée dans le temps, HTTP pour les profils locaux (#28)
Le first-run wizard restait figé : `CliAgentRuntime::detect` construisait un
runtime tokio courant-thread via `futures_block_on` pour piloter un
`ProcessSpawner` async. Appelé depuis le runtime async de Tauri, ce
`block_on` imbriqué panique ; la commande IPC ne répond alors jamais, la
promesse `detectProfiles` reste pendante et `busy` ne redescend plus.

Ce commit s'attaque à la cause côté backend :

- `AgentRuntime::detect` devient `async fn` (`#[async_trait]`) : le port cesse
  de mentir sur sa nature. Il pilote un spawner async, il est async. Le
  `futures_block_on` disparaît, et avec lui le runtime imbriqué.
- La sonde CLI est bornée par `tokio::time::timeout(DETECTION_TIMEOUT)` :
  un binaire qui ne rend jamais la main dégrade la détection en `Err`, il
  ne gèle plus l'appelant.
- Les profils `StructuredAdapter::OpenAiCompatible` n'ont pas de CLI à
  spawner : les sonder revenait à tester un binaire inexistant. Ils sont
  désormais sondés par un GET HTTP sur l'endpoint `/models` dérivé de
  `chat_http.endpoint`, borné par le même timeout.

`DetectProfiles` séquence les `await` sur les candidats. Les fakes
`AgentRuntime` des crates application/infrastructure/app-tauri suivent la
nouvelle signature.

Tests: cargo test -p domain (241), -p application (81), -p infrastructure
(269), -p app-tauri (63+15) — verts. `rg futures_block_on crates` sans match.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-08 08:11:14 +02:00
3c6cd04bd8 Merge feature/ticket14-local-lan-profiles into develop (#14)
Intègre les profils IA locaux/LAN OpenAI-compatible comme profils IdeA
canoniques (adapter HTTP additif, parité tool-calling/MCP).

Backend (aab4bca) + frontend (d89380c), validés GO par QA de bout en bout.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 22:35:08 +02:00
d89380cdf0 feat(ui): profils locaux/LAN OpenAI-compatible dans le first-run et les terminaux (#14)
Câble la surface frontend des profils IA locaux/LAN OpenAI-compatible,
en parité avec l'adapter backend additif (aab4bca).

- domain: types de profil OpenAI-compatible
- first-run: édition/validation du profil dans le FirstRunWizard
- adapters/mock: mock de profil pour les tests
- terminals: rendu des round-trips et erreurs endpoint (role=alert)

Validé QA (frontend GO): typecheck exit 0, vitest 59 fichiers / 566 tests,
0 echec ; couverture timeouts round-trip + erreur endpoint role=alert
prouvees ; pas de regression sur les tests de bail headless.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 22:34:50 +02:00
aab4bcafb6 feat(session): adapter HTTP OpenAI-compatible pour profils locaux/LAN (#14)
Ajoute un adapter de session HTTP OpenAI-compatible, purement additif,
permettant d'intégrer des modèles locaux/LAN comme profils IdeA canoniques
avec parité tool-calling/MCP.

- domain: extension du profil et des ports pour l'adapter OpenAI-compatible
- infrastructure: adapter openai_compat + routage factory
- app-tauri: mapping des outils OpenAI (openai_tools) + wiring state/lib
- application: catalogue d'agents + tests de use-cases profils

Validé QA (backend GO): round-trip byte-identique Claude/Codex, mapping
erreurs, dégradation tools, conversation_id None, conformance un seul Final,
routage factory. Suites vertes domain 467 / application 530 /
infrastructure 523 / app-tauri 247, 0 échec.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 22:09:16 +02:00
cb20fabdf4 Merge feature/ticket25-assistant-sandbox-plan into develop (#25)
fix(assistant): retire le plan sandbox project_read_only qui provoquait
l'EACCES/os error 13 au spawn de la CLI de l'assistant de ticket.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 17:28:37 +02:00
961a2cadc4 fix(assistant): retire le plan sandbox project_read_only de l'assistant de ticket (#25)
La surface « assistant de ticket » imposait un SessionPlan Landlock
restrictif (project_read_only) qui gouvernait la classe exec de la
sandbox OS et empêchait le spawn de la CLI (EACCES / os error 13).

factory.start reçoit désormais SessionPlan::None + sandbox absent :
l'assistant n'impose plus ce plan OS-sandbox. La classe exec n'est
plus verrouillée, le spawn de la CLI aboutit.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 17:28:30 +02:00
47b1d64e39 Merge feature/ticket23-system-view-windows into develop (#23)
Fenêtres View système séparées (WebviewWindow Tauri, multi-écran,
fullscreen) — backend commandes/capabilities + composition root,
frontend port WindowGateway + entrée panel-only. Clôt le sprint
UI rework. QA vert : app-tauri 63, frontend typecheck + vitest 546/546.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 16:53:52 +02:00
69e785ec7e feat(ui): fenêtres View système séparées — WebviewWindow Tauri + port WindowGateway (#23)
Détache les vues dans de vraies fenêtres système Tauri (multi-écran,
fullscreen). Backend : commandes de gestion de WebviewWindow, capabilities
et composition root. Frontend : nouveau port WindowGateway et son adaptateur
window, entrée panel-only ViewWindow/ViewPanelBody, détachement câblé dans
ProjectsView. QA vert : app-tauri 63, frontend typecheck + vitest 546/546.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 16:53:43 +02:00
2323a71f01 Merge feature/ticket22-view-anchor-docking into develop (#22)
Anchor de views — primitive de docking DockRegion + modèle ViewPlacement,
câblés dans ProjectsView. QA vert : frontend typecheck + vitest 537/537.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 11:54:50 +02:00
37bf7d4167 Merge feature/ticket21-sort-tickets into develop (#21)
Tri de la liste de tickets — backend (TicketListQuery/ticket_list, MCP)
+ frontend (contrôle « Trier par… » dans TicketFacetsBar). QA vert :
app-tauri 60+15, infrastructure 254, frontend typecheck + vitest 533/533.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 11:54:44 +02:00
bd73fd79bd feat(tickets): contrôle « Trier par… » dans la barre de facettes (#21)
Ajoute le sélecteur de tri dans TicketFacetsBar et propage le critère
via useTicketSearch jusqu'à TicketsPanel et TicketPicker, sur le contrat
de tri backend (e523f44). Couvre le tri par les tests tickets et
TicketPicker.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 11:54:28 +02:00
e523f44425 feat(tickets): tri de la liste de tickets côté backend (#21)
Ajoute le paramètre de tri dans TicketListQuery et l'expose via
ticket_list (surface app-tauri + MCP). Ports et adaptateur mock
frontend alignés sur le contrat de tri. La partie UI (contrôle de tri
dans TicketFacetsBar) suivra dans un commit frontend dédié.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 11:45:59 +02:00
419e9b8498 feat(ui): anchor de views — primitive de docking DockRegion + modèle ViewPlacement (#22)
Introduit la primitive de docking DockRegion et le modèle ViewPlacement
pour ancrer les vues dans le chrome, câblés dans ProjectsView. Tests
unitaires DockRegion et test d'intégration docking de ProjectsView.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 11:45:46 +02:00
2f8467e2dd Merge feature/ticket17-focus-trap-fix into develop
fix(tickets): perte de focus dans l'édition d'un ticket (#17) — focus-trap
FloatingWindow passé en mount-only via onCloseRef, + test de régression.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 08:28:15 +02:00
4cccd40e2a fix(tickets): corrige la perte de focus dans l'édition d'un ticket (#17)
Le focus-trap de FloatingWindow avait un useEffect dépendant de `[onClose]`.
`onClose` (ex. TicketDetail.requestClose) est une closure recréée à chaque
render : chaque frappe ré-armait l'effet et renvoyait le focus au premier
élément focusable, ne laissant saisir qu'une lettre à la fois dans le
formulaire d'édition.

Correctif : conserver le dernier `onClose` dans un `onCloseRef` et passer
l'effet focus-trap en mount-only (`[]`). Le handler Escape lit la valeur
courante via la ref. Ajout d'un test de régression prouvé rouge-sans /
vert-avec le fix.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 08:28:08 +02:00
f580edc93a Merge feature/tickets-window into develop
Lot C du sprint UI rework : fenêtre dédiée de gestion des tickets (#17).
Clôt le sprint UI rework (#16, #18, #19, #17 intégrés).
Tests verts (tsc clean, suite complète 530/530).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 06:35:26 +02:00
7caced1b99 feat(tickets): fenêtre dédiée de gestion des tickets — liens via popup + assistant IA flottant (#17)
Lot C du sprint UI rework : fenêtre dédiée de gestion des tickets,
appuyée sur la primitive FloatingWindow (#16) et la popup TicketPicker (#18).

- TicketDetail : gestion des liens de ticket via la popup TicketPicker,
  assistant IA en fenêtre flottante
- FloatingWindow : ajustements pour l'usage fenêtre dédiée

Tests : tsc --noEmit clean, suite complète 530/530, suites tickets +
FloatingWindow 50/50.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 06:35:20 +02:00
cb8c9cd634 Merge feature/sprint-ticket-picker into develop
Lot D du sprint UI rework : TicketPicker branché dans la gestion de sprint (#19).
Tests verts (tsc clean, suite complète 528/528, tickets 38/38).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-06 21:01:16 +02:00
5a0d9f0db4 feat(tickets): sélection de ticket via popup dans la gestion de sprint (#19)
Lot D du sprint UI rework : branche la popup réutilisable TicketPicker (#18)
dans la sélection de ticket de la création/édition de sprint.

- SprintManager : sélection de ticket déléguée à la popup TicketPicker
- TicketsPanel : ajustements liés à l'intégration

Tests : tsc --noEmit clean, suite complète 528/528, suite tickets 38/38
(dont 2 nouveaux tests #19).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-06 21:01:06 +02:00
a118069f80 Merge feature/ui-menus-floating into develop
Lot A du sprint UI rework : menus déroulants, FloatingWindow, barre unique
et sélecteur de projet permanent (#16). Débloque le lot C #17.
Tests verts (tsc clean, suite complète 527/527).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-06 20:55:43 +02:00
c55f948d25 feat(ui): menus déroulants + fenêtres flottantes, barre unique et sélecteur de projet (#16)
Lot A du sprint UI rework : réorganisation de la navigation racine.

- shared/ui/MenuBar.tsx : barre de menus unique avec menus déroulants
- shared/ui/FloatingWindow.tsx : primitive de fenêtre flottante réutilisable
  (socle du lot C #17 fenêtre dédiée gestion tickets)
- shared/ui/zIndex.ts : échelle z-index étendue pour les fenêtres flottantes
- App : intègre la barre unique et le sélecteur de projet permanent
- ProjectsView : sélecteur de projet permanent

Tests : tsc --noEmit clean, suite complète 527/527, suites impactées 33/33.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-06 20:55:37 +02:00
0218e3271f Merge feature/ticket-picker-popup into develop
Lot B du sprint UI rework : popup réutilisable TicketPicker (#18).
Tests verts (TicketPicker 8/8, suite tickets 37/37, tsc clean).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-06 15:54:53 +02:00
140daae8b3 feat(tickets): popup réutilisable de sélection de ticket (#18)
Ajoute TicketPicker, popup modale réutilisable de sélection de ticket,
socle du chemin critique du sprint UI rework (#17 et #19 en dépendent).

- TicketPicker.tsx : popup de recherche/sélection réutilisable
- useTicketSearch.ts : hook de recherche/filtrage extrait et partagé
- TicketFacetsBar.tsx : barre de facettes extraite de TicketsPanel
  pour réutilisation (listing principal + picker)
- shared/ui/zIndex.ts : échelle z-index centralisée
- TicketsPanel : consomme la barre de facettes extraite

Tests : TicketPicker.test.tsx 8/8, suite tickets 37/37, tsc --noEmit clean.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-06 15:54:47 +02:00
d97abb116f Merge feature/work-state-dto-debt into develop
Dette de contrat DTO work-state (#5, frontend) : summary sur BackgroundCompletion
mappé depuis task.summary, affichage discret sur tâche terminale, suppression du
chemin de merge top-level mort. Tests verts.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-06 11:05:11 +02:00
3d603cebcc feat(workstate): dette de contrat DTO work-state (frontend)
Aligne le contrat DTO du panneau work-state (#5).

- ajout summary: string|null à BackgroundCompletion, mappé depuis task.summary
- affichage discret du résumé sur une tâche terminale
- suppression du chemin de merge top-level mort des background tasks

Tests verts : vitest workstate.test.tsx (21), suite complète (507),
npm run build (exit 0).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-06 11:05:03 +02:00
4bdffa4baa Merge feature/ticket-filter-checkboxes into develop
Filtres multi-critères par cases à cocher (#12) : backend (IssueListFilter en Vec
statuses/priorities, filter_matches OR/AND, DTO en tableaux, MCP idea_ticket_list
aligné) et frontend (TicketListQuery multi-valeurs, UI checkboxes, toggle/clear).
Tests verts.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-06 06:41:11 +02:00
feeca3462c feat(tickets): filtres multi-critères par cases à cocher (backend + frontend)
Passe les filtres de la liste des tickets en sélection multiple (#12).

Backend Rust :
- IssueListFilter : statuses/priorities en Vec, filter_matches en OR intra-champ
  et AND inter-champs
- TicketListRequestDto en tableaux + from_request (parse/déduplication)
- MCP idea_ticket_list aligné sur le nouveau contrat

Frontend :
- TicketListQuery.statuses/priorities
- UI de cases à cocher, toggle/clear des filtres

Tests verts : issue_store (7), app-tauri --lib (59), mcp_server (24),
issue_usecases (6), sprint_usecases (6), frontend vitest (505), npm run build (exit 0).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-06 06:41:01 +02:00
413db25f08 Merge feature/ticket-deletion into develop
Suppression d'un ticket (#6) : backend (IssueStore::delete, FsIssueStore::delete
sous lock, use case DeleteIssue, event IssueDeleted, commande ticket_delete) et
frontend (gateway delete, retrait de liste/fermeture détail via event). Tests verts.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-06 06:27:15 +02:00
5417bd756b feat(tickets): suppression d'un ticket (backend + frontend)
Ajoute la suppression complète d'un ticket (#6).

Backend Rust :
- port IssueStore::delete (NotFound si absent) + event IssueDeleted{freed_sprint}
- FsIssueStore::delete : supprime .ideai/tickets/<N>/ et l'index sous lock
- use case DeleteIssue + adaptations des tests sprint/ticket_assistant au port
- commande Tauri ticket_delete + câblage events/state/lib

Frontend :
- gateway delete (ports, adapter ticket + mock, domain)
- useTicketDetail : retrait de la liste et fermeture du détail via event issueDeleted
- intégration TicketDetail + tests

Tests verts : application/issue_usecases (6), infrastructure/issue_store (7),
app-tauri --lib (56), frontend vitest (503), npm run build (exit 0).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-06 06:27:09 +02:00
d25e340b44 Merge feature/ticket-ai-assistant into develop
Assistant IA de ticket (#8) : backend (use cases open/close, policy d'outils
par agent, store de contexte assistant, events, commandes Tauri) et frontend
(gateway, hook, panneau, intégration TicketDetail). Tests verts.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-06 06:06:32 +02:00
1fdf62c089 feat(tickets): création d'un assistant IA de ticket (backend + frontend)
Ajoute le chat assistant IA attaché à un ticket (#8).

Backend Rust :
- use cases OpenTicketAssistant/CloseTicketAssistant + tests
- politique d'outils par agent (domain/agent_tool_policy) et policy MCP
- store de contexte assistant + gabarit default_ticket_assistant.md + tests
- events TicketAssistantOpened/Closed
- commandes Tauri open_ticket_chat/close_ticket_chat et câblage state/lib/events

Frontend :
- gateway (ports, adapters ticket + mock, domain)
- hook useTicketAssistant + composant TicketAssistantPanel
- intégration dans TicketDetail

Tests verts : vitest tickets.test.tsx (23), cargo test application::ticket_assistant (1),
infrastructure::assistant_context_store (2).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-06 06:06:24 +02:00
f1803768fd Merge feature/sprint-management-ui into develop
Ticket #11 : interface de création et gestion des sprints (frontend pur) —
SprintManager, useTickets, ports/adaptateurs et TicketsPanel. Suite frontend
verte (typecheck + vitest 497+ tests + build).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-05 21:11:46 +02:00
fa874b976e feat(sprints): interface de création et gestion des sprints (frontend)
Ticket #11 — surface UI de gestion des sprints (frontend pur).

- Nouveau composant SprintManager : création (nom optionnel), édition et
  gestion du cycle de vie d'un sprint, contrôles accessibles (pas de DnD).
- useTickets étendu aux opérations de gestion de sprint ; ports, adaptateurs
  (ticket.ts, mock/index.ts) et TicketsPanel câblés en conséquence.
- Tests Vitest associés (tickets.test.tsx).

Typecheck / vitest (497+ tests) / build verts.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-05 21:11:37 +02:00
edd5486330 Merge feature/sprint-model into develop
Ticket #10 : modèle de sprints — agrégat domaine, use-cases, persistance,
exposition MCP et app-tauri (backend) + surface frontend (adaptateurs, ports,
UI tickets). Suite complète verte (domaine/application/infra/app-tauri +
frontend typecheck/vitest/build).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-05 10:57:44 +02:00
69759d351c feat(sprints): surface frontend du modèle de sprints
Ticket #10 — volet frontend des sprints.

- Domaine et ports frontend étendus au modèle de sprints (domain/index.ts,
  ports/index.ts).
- Adaptateurs : ticket.ts et mock/index.ts câblent les opérations sprints.
- UI tickets : useTickets + TicketsPanel exposent le rattachement/gestion des
  sprints, avec tests Vitest associés.

Typecheck / vitest / build verts.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-05 10:57:38 +02:00
48b652ff91 feat(sprints): modèle de sprints — domaine, use-cases, persistance et surfaces (backend)
Ticket #10 — introduction du modèle de sprints côté backend.

- Domaine : nouvel agrégat Sprint (sprint.rs), IDs, événements et invariants ;
  rattachement des issues à un sprint (issue.rs) et ports associés.
- Application : use-cases sprints (application/src/sprints) + erreurs dédiées.
- Infrastructure : store de sprints (infrastructure/src/sprints.rs), adaptation
  du store d'issues et exposition MCP via orchestrator/mcp/tickets.rs.
- app-tauri : commandes, state et events pour piloter les sprints depuis l'UI.

Tests domaine/application/infra/app-tauri verts (sprint_usecases, sprint_store,
issue_store, mcp_server).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-05 10:57:33 +02:00
9740149ebb Merge feature/ticket-edit-persistence into develop
Ticket #9 : persistance de l'édition d'un ticket côté frontend
(useTicketDetail + TicketDetail), tests Vitest tickets verts (13/13).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-05 02:20:29 +02:00
5ecc64f9c5 feat(tickets): persistance de l'édition d'un ticket côté frontend
Ticket #9 — l'édition d'un ticket (titre, corps, champs) est désormais
persistée depuis le détail : useTicketDetail porte l'état d'édition et le
flux de sauvegarde, TicketDetail expose l'UI d'édition/validation.

Tests Vitest tickets verts (13/13), typecheck et build OK.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-05 02:20:23 +02:00
ce6ef5efae Merge feature/agent-live-announcements into develop
Intègre les annonces live inter-agent (ticket #4) : backend du tap
mpsc live (B0-B3), surface frontend des annonces sur les cellules
(F1-F3), et les notes projet associées.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-04 20:11:21 +02:00
f0adf2dcc4 docs(memory): notes projet du redémarrage des annonces live (ticket #4)
Notes du chantier #4 relancé sur develop, commit séparé du code
(convention d'usage) :

- ticket4-restart-on-develop-ebd992e: baseline de redémarrage.
- ticket4-overlay-composition-leafview: décision de composition de l'overlay
  dans le layout (LeafView).
- ticket4-announcements-frontend-f1f2f3: cadrage de la surface frontend F1-F3.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-04 19:50:22 +02:00
50b2adfde3 feat(inter-agent): surface frontend des annonces live sur les cellules (F1-F3)
Affiche les annonces d'agent en direct au-dessus des cellules, sur la base
develop :

- announcements: nouveau feature module — store réactif, provider
  d'abonnement aux événements, overlay par cible et aperçu, avec tests
  (announcementsStore + provider).
- App.tsx: montage du provider dans l'arbre applicatif.
- domain/index.ts: types partagés de l'événement d'annonce côté front.
- layout: composition de l'overlay dans LayoutGrid + règle d'exclusion
  couverte par overlayExclusion.test.ts.
- AgentsPanel: intègre l'aperçu des annonces dans la surface existante.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-04 19:50:13 +02:00
aa5a4f30ae feat(inter-agent): backend des annonces live d'agent (B0-B3)
Redémarre le ticket #4 sur la base develop. Émission d'annonces live d'un
agent vers l'UI, distinctes du Final de délégation :

- domain: ReplyEvent::Announcement/Final et DomainEvent::AgentAnnouncement
  (events.rs), port d'émission (ports.rs), gating de readiness (readiness.rs).
- application: mapping des événements structurés en annonces
  (agent/structured.rs, agent/mod.rs, lib.rs) et relais côté orchestrateur
  (orchestrator/service.rs).
- infrastructure/session: parse des annonces + fix du Final pour Claude et
  Codex, propagé aux adaptateurs et à la conformance
  (claude.rs, codex.rs, conformance.rs, mod.rs, process.rs, sandbox_e2e.rs).
- app-tauri: relais Tauri des annonces vers le front (events.rs, chat.rs).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-04 19:50:03 +02:00
ebd992e41a docs(memory): notes projet tâches de fond, tickets V1 et checkpoints ticket #1
Capitalise la mémoire projet accumulée pendant les chantiers B7/B8
(tâches de fond first-class), le système de tickets V1 et le ticket #1 :
design, cadrages d'archi, checkpoints d'avancement et verdicts QA/frontend.
Mise à jour de l'index MEMORY.md.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-04 00:21:43 +02:00
eb9cc16181 feat(background): livraison auto au propriétaire + projection des tâches de fond dans le work-state (T1+T3)
T1 — Wake automatique du propriétaire à la complétion.
La complétion d'une tâche de fond est désormais livrée à l'agent
propriétaire dès que la session accepte l'envoi (wake.rs :
mark_completion_delivered au send accepté), via un drain de flux dédié
(structured.rs : drain_reply_stream_with_readiness). L'inbox médiée
enfile l'item sans démarrer de tour ni marquer l'agent busy
(input/mod.rs : enqueue FIFO silencieux). Régression couverte
(tests/agent_wake.rs, tests input/mod.rs).

T3 — Tâches de fond projetées dans le read-model du panneau Work.
AgentWorkState porte désormais background_tasks
(VO AgentBackgroundTaskState), alimenté par un builder best-effort
with_background_tasks(store) : union list_open_for_agent + dispatch des
completions non livrées par owner_agent_id, erreur store => Vec vide
(aucune régression live/busy/tickets). DTO Tauri backgroundTasks et
wiring du BackgroundTaskStore côté state.rs. Le frontend, déjà câblé,
affiche Cancel/Retry (mapping queued/waiting -> pending, tri sur
updatedAtMs). Borne V1 : une tâche terminale déjà livrée n'est plus
énumérable (Retry limité à la fenêtre non livrée).

Tests : cargo build --workspace OK ; cargo test -p application /
-p app-tauri / -p infrastructure verts ; frontend build + vitest verts.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-04 00:21:33 +02:00
f08dae62eb feat(background): déclencheur in-app des tâches de fond via MCP idea_run_in_background (BE-1+BE-2)
Ferme la boucle B8 côté surface agent : un agent peut lancer une commande
en tâche de fond depuis l'app, sans dépendance à un déclencheur externe.

- domain : variante OrchestratorCommand::RunInBackground.
- infrastructure : outil MCP idea_run_in_background (déclaration + schéma +
  map_tool_call), tests de mapping et compteur de catalogue.
- application : handler → SpawnBackgroundCommand (owner=requester, WakeOwner).
- app-tauri : câblage .with_spawn_background_command + catalogue MCP 23→24.

Tests verts : domain 452 / application 467 / infrastructure 489 /
app-tauri 236, build --release vert.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-03 22:44:48 +02:00
41278bd632 Merge branch 'feature/issue-ticket-system' into feature/background-tasks-first-class
Intègre le système de tickets/issues V1 (validé QA vert de bout en bout,
mémoire tickets-v1-e2e-validated-qa) dans la branche des tâches de fond.
Conflits résolus : app-tauri/state.rs, domain/events.rs, domain/lib.rs, domain/ports.rs.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-03 15:15:43 +02:00
c179f93a26 feat(frontend): boutons cancel/retry des tâches de fond (B8)
Câble l'action utilisateur sur les commandes Tauri B8 :

- port WorkStateGateway : ajout de cancelBackgroundTask/retryBackgroundTask
  (le read-model se rafraîchit via l'événement domaine backgroundTaskChanged ;
  retry rejoue sous un NOUVEL id de tâche).
- adapter Tauri : invoke cancel_background_task/retry_background_task.
- adapter mock : no-ops (le refresh réel est piloté par les événements).
- ProjectWorkStatePanel (BackgroundTaskRow) : état busy + affichage d'erreur
  + refresh après action.
- test ProjectsView.ls7 : stub de gateway complété.

Build vert : npm run build (tsc --noEmit + vite build), vitest 449 passed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-03 14:53:32 +02:00
8cac1470ac feat(background): runner PTY B8 + boucle sink fermée + refactor point-2
Livre le lot backend B8 des tâches de fond :

- infrastructure : runner de commandes concret (CommandBackgroundRunner)
  sur le port BackgroundTaskRunner, tail borné (bounded_tail/BoundedTail),
  éclatement du module background_task en sous-modules (mod/runner/tail,
  sink extrait de l'ancien background_task.rs).
- application : nouveau module background exposant les cas d'usage
  SpawnBackgroundCommand, CancelBackgroundTask, RetryBackgroundTask et le
  port BackgroundCommandArchive.
- domain : refactor point-2 de l'arbitrage Architect — sortie du trait
  BackgroundCommandArchive de la couche domaine vers application.
- app-tauri : câblage runtime (commands, dto, state, lib) des commandes
  spawn/cancel/retry et de la boucle de complétion sink fermée en
  composition root.

Build workspace + tests application/infrastructure verts (QA).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-03 14:48:46 +02:00
c1d82eee8d feat(tickets): surface frontend V1 du système de tickets
Surface UI complète des tickets (domaine Issue exposé « ticket »),
validée QA de bout en bout : cargo build + tests backend verts,
npm run build + npm test (459) verts.

- Domaine : DTO Ticket, 9 events Issue* + guard isTicketEvent.
- Ports : TicketGateway (+ types query/input) ajouté à Gateways.
- Adapters : TauriTicketGateway réel (+ isTicketVersionConflict),
  wiring, et MockTicketGateway pour les tests.
- Feature tickets : hooks (useTickets, useTicketDetail,
  useProjectAgents), TicketsPanel, TicketDetail, TicketsView,
  ticketMeta + tests.
- ProjectsView : onglet sidebar « Tickets ».

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-02 22:56:36 +02:00
8de7be01a8 feat(tickets): checkpoint backend V1 du système de tickets (T1-T5)
Checkpoint de travail — QA formelle encore à venir (après reset Codex).
`cargo build` workspace OK, tests ticket/issue verts (domaine, store,
use cases, app-tauri 47/51). Le domaine s'appelle `Issue`, exposé
« ticket » côté MCP/UI.

- T1 domaine : entité Issue (statut, priorité, liens, carnet),
  events, ids, ports.
- T2 infra : store FS Markdown + allocator de références #N.
- T3 application : use cases Issue (create/read/list/update/status/
  priority/carnet/link/unlink/assign) + erreurs dédiées.
- T4 surface MCP : 10 outils publics idea_ticket_* (23 outils au
  total), mappés vers les use cases Issue.
- T5 app-tauri : commandes Tauri ticket_* + DTOs d'events Issue +
  câblage state.rs.

Dette de test PRÉ-EXISTANTE héritée de develop (4 tests app-tauri
mcp_e2e_loopback / mcp_serve_peer rouges) hors périmètre tickets,
non traitée ici.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-02 22:34:04 +02:00
5d88c952ec feat(frontend): surface UI des tâches de fond (F1-F4)
Expose les tâches de fond côté front : modèle domaine et
normalisation du work state, panneau ProjectWorkStatePanel,
intégration dans LayoutGrid et ProjectsView, et abonnement aux
événements backgroundTaskChanged / agentInboxChanged /
agentWakeChanged pour rafraîchir l'état. npm run build + npm test
(449) verts.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-02 21:33:51 +02:00
e05edc6863 feat(app-tauri): câblage runtime des tâches de fond (B7)
Branche le store de tâches de fond dans le runtime : store per-root
routé par project_id, AppReconcileBackgroundTasks au boot,
AppWakeSessionProvider et boucle ready→MediatedInbox→AgentWakeService,
avec .with_background_tasks(store, clock) au builder OrchestratorService.
open_project appelle reconcile_background_tasks au démarrage.

Aligne aussi 4 tests MCP périmés de l'ancien protocole : idea_reply
retiré (erreur JSON-RPC -32601), idea_ask_agent exposé (13 tools),
rendez-vous capture le Final inline. cargo test -p app-tauri --lib
= 52 passed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-02 21:33:45 +02:00
54c8ecfab7 feat(app-tauri): événements des tâches de fond exposés au front (B1-B6)
Câblage des événements de complétion/mailbox/réveil vers la couche
app-tauri pour consommation par le frontend (lots F1-F4 à venir).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-02 15:47:39 +02:00
f94b54239b feat(application): réveil d'agent et rendez-vous comme tâche de fond (B5-B6)
Orchestration du réveil (wake) d'un agent sur complétion/message et
traitement du rendez-vous inter-agent comme tâche de fond de 1re classe.
Couvert par agent_wake (vert).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-02 15:47:34 +02:00
c537da54ef feat(infrastructure): store, sink de complétion et mailbox des tâches de fond (B2-B4)
Adapters de persistance des BackgroundTask (store), sink de récupération
de complétion post-tour et boîte de réception (mailbox) pour les messages
concurrents, câblés sur l'entrée. Couvert par background_task_store,
background_completion_sink, agent_inbox et orchestrator_watcher (verts).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-02 15:47:28 +02:00
f4a55e9988 feat(domain): modèle de tâches de fond de 1re classe et mailbox (B1)
Entités BackgroundTask et Inbox, identifiants, événements et ports du
domaine pour la récupération de complétion post-tour et la réception de
messages concurrents. Fondations des lots infra/application suivants.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-02 15:47:16 +02:00
fccc1e2f0f chore(gitignore): ignore les target/ de sous-crates Cargo
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-02 14:49:45 +02:00
62915eec4d fix(codex): dernier agent_message = Final (bootstrap canal)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-02 14:49:00 +02:00
a9653bc417 fix(orchestrator): délégation inter-agent toujours headless, jamais d'injection PTY
La conversation inter-agent (idea_ask_agent) doit rester strictement
headless : la cible répond via une session structured capturée par IdeA,
sans jamais écrire dans le PTY d'une cellule visible ni fermer le terminal
que l'utilisateur observe.

- lifecycle: flag `allow_structured_alongside_pty` — ouvre une session
  structured pour la délégation sans fermer le PTY visible (coexistence).
- orchestrator/service: `ensure_structured_session` ne ferme plus le PTY
  visible ; mapping typé de l'erreur no-reply ; coexistence PTY/structured.
- infrastructure/input: garantit zéro `DelegationReady` et zéro write PTY
  pour une délégation headless, même quand l'entrée est `front_owned`.
- app-tauri (commands/state): câblage du flag de coexistence.
- tests: fixtures portées vers le modèle structured/headless, assertions
  cibles mises à jour (aucun #[ignore] ajouté, aucun test retiré).

Validé réel : cargo build OK ; orchestrator_service 60/0, agent_lifecycle
62/0, structured_launch_d3 22/0, infrastructure input 35/0.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-02 10:22:06 +02:00
1fc7869160 agent conversation fix 2026-06-27 12:42:37 +02:00
c2d1a669c5 agents profiles added to gitignore 2026-06-27 12:06:25 +02:00
62e41bda66 merge(layout): intègre l'auto-réparation de l'onglet
actif stale

Co-Authored-By: Claude Opus 4.8
    <noreply@anthropic.com>
2026-06-25 16:23:40 +02:00
e916ecd95e fix(layout): auto-réparer l'onglet actif
stale

Le backend renvoie l'id actif autoritaire et le
    frontend l'adopte pour éviter de rejouer un layout
    disparu après overwrite externe.

Co-Authored-By: Claude Opus 4.8
    <noreply@anthropic.com>
2026-06-25 16:23:40 +02:00
137620daa3 chore(gitignore): détrack .ideai/layouts.json (état UI runtime machine-local)
layouts.json portait l'état UI runtime (active layout id + session ids),
reconstruit à l'exécution et last-writer-wins — même catégorie que
.ideai/live-state.json déjà ignoré. Versionné à tort, il était écrasé par
git au switch de branche → activeId périmé → "not found: layout X" → cellules
figées. On le détrack (git rm --cached, fichier conservé sur disque) et on
l'ajoute au .gitignore sous le bloc live-state. Le fix runtime (self-heal de
l'active layout) viendra dans un commit séparé sur cette branche.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-24 13:46:08 +02:00
d7145644d9 merge(orchestrator): intègre le watchdog d'inactivité réarmable + plafond du rendez-vous (T7)
Fenêtre d'inactivité réarmée à chaque progrès de la cible (octets cumulés du
transcript) sous un plafond absolu, en remplacement du timeout plat qui coupait
un long tour unique à 600 s. Issue typée TargetCeilingActive distincte du no-reply.
Suite Rust verte (application + infrastructure, 0 échec). Campagne MCP T1→T10 PASS.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-24 13:33:18 +02:00
50e99e5ced chore(workstate): notes mémoire campagne MCP T1→T10 + état runtime
Capitalise la mémoire projet produite pendant la campagne de tests fonctionnels
MCP (rendez-vous inter-agents, backstop no-reply, réconciliation live-state au
reboot) et synchronise l'état runtime `.ideai/` (agents, layouts, skills, index
mémoire). Inclut la mise à jour du contexte de l'agent Git.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-24 13:32:28 +02:00
6050a6da5f feat(orchestrator): watchdog d'inactivité réarmable + plafond du rendez-vous inter-agents
Redessine la borne de fin de tour du rendez-vous `idea_ask_agent` ⇄ `idea_reply` :
au lieu d'un timeout plat (qui coupait à 600 s un seul long tour de la cible, cf.
T7), la borne devient une **fenêtre d'inactivité réarmée** à chaque progrès observé
de la cible, sous un **plafond absolu** (défaut 4 h, réglable via
`IDEA_ASK_RENDEZVOUS_CEILING_MS`).

- Sonde d'activité (`transcript_activity_token`, inspector) : jeton monotone =
  octets cumulés des `.jsonl` de la cible. Croît même pendant un seul long tour
  sans `turn_duration` ⇒ détecte « vivant et au travail » mi-tour. Best-effort,
  sans effet de bord ; folder absent/illisible ⇒ « pas de progrès ».
- Watchdog (`run_inactivity_watchdog`, nouveau module `orchestrator/rendezvous`) :
  fenêtre réarmable + plafond, fallback timeout plat si aucune sonde (zéro régression).
- Issue typée distincte `TargetCeilingActive` (code `RENDEZVOUS_CEILING_ACTIVE`) :
  une cible **active** stoppée au plafond n'est jamais confondue avec un
  `TargetReturnedNoReply` (silence) ; le message guide « ne pas retenter à l'aveugle ».
- Câblage composition-root (`state.rs`) : sonde résolue nom→AgentId→run-dir transcript,
  branchée sur le service et sur l'McpServer (`AskActivityProbe`, `with_ask_ceiling`).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-24 13:32:19 +02:00
1efe2f11dc merge(workstate): intègre la réconciliation du live-state au reboot (ReconcileLiveState)
Intègre feature/reconcile-live-state : à l'ouverture d'un projet, les statuts
d'agents restés `working` fantôme après un redémarrage sont réconciliés vers
`idle` (use case ReconcileLiveState, best-effort, sans nouveau port).

QA VERT : cargo test --workspace 1624 passed / 0 failed, clippy 0 erreur.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-23 20:18:39 +02:00
886bb0d761 feat(workstate): réconcilie le live-state au reboot (use case ReconcileLiveState)
Au redémarrage, les agents qui étaient `working` lors de la fermeture restaient
figés en statut fantôme `working` alors qu'aucun tour n'est plus en cours (bug
reproductible en live : QA et DevBackend eux-mêmes sont restés `working` fantôme
après leurs tâches). On réconcilie l'état persistant à l'ouverture du projet :
les statuts orphelins sont ramenés à la cible `idle`.

- domain/live_state.rs : const STALE_AT_RESTART_MARKER + `reconcile_orphans` (+ tests).
- application/workstate/reconcile.rs (nouveau) : use case ReconcileLiveState (pas de
  nouveau port), best-effort, no-op si store vide (+ tests, dont empty_store_is_a_noop_at_boot).
- application/workstate/mod.rs + lib.rs : module + re-export.
- app-tauri/state.rs : provider par-root + champ AppState + wiring.
- app-tauri/commands.rs : hook best-effort dans open_project.

QA VERT par commande réelle : cargo test --workspace 1624 passed / 0 failed,
cargo clippy --workspace --all-targets 0 erreur sur le code ajouté.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-23 20:18:25 +02:00
15cf21c5bd merge(orchestrator): intègre le backstop no-reply + cause racine encode_cwd (rendez-vous inter-agents)
Intègre la branche feature/rendezvous-no-reply-backstop : durcissement du
rendez-vous idea_ask_agent ⇄ idea_reply, backstop no-reply, et le fix de cause
racine `encode_cwd` (encodage exact de Claude Code, `.` -> `-`) qui rétablit le
turn-watcher et lève le wedge.

Validé EN LIVE (wedge prouvé levé, demandeur libéré via grâce 2s) + suite verte
(cargo test --workspace 1616 passed / 0 failed, clippy 0 erreur).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-23 19:51:05 +02:00
c6f0f86f0e fix(inspector): encode_cwd réplique l'encodage exact de Claude Code (cause racine du wedge no-reply)
`encode_cwd` ne remplaçait que `/` et `\` par `-`, laissant le `.` intact. Or
Claude Code aplatit le cwd via `replace(/[^a-zA-Z0-9]/g, '-')` : tout caractère
non alphanumérique devient `-`, y compris le `.`. Pour un run dir isolé
`…/IdeA/.ideai/run/<uuid>`, le `/.` doit collapser en double dash
(`…-IdeA--ideai-run-<uuid>`). L'ancienne version calculait `…-IdeA-.ideai-run-…`,
un dossier inexistant sur disque : le turn-watcher voyait un répertoire vide
(baseline 0, conversation <none>) et ne déclenchait jamais `turn_ended`, ce qui
wedgeait le backstop no-reply du rendez-vous inter-agents.

Validé EN LIVE : demandeur libéré ~grâce 2s (au lieu du timeout 600s), preuves
dans idea.log. Test de non-régression `encode_cwd_encodes_dot_in_run_dir_to_double_dash`
+ maj test Windows (`C:\Users\me` -> `C--Users-me`).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-23 19:50:58 +02:00
744de20f4b feat(orchestrator): backstop no-reply du rendez-vous inter-agents
Remédiation du wedge persistant après échec live du fix Finding A (77e62e5).
Détecte la fin de tour d'un agent sollicité qui n'a pas appelé idea_reply et
débloque l'agent demandeur au lieu de le laisser en attente indéfinie.

Ajoute le suivi de tour côté inspector Claude (claude_turn_watcher) et la
résolution des chemins de session (claude_paths), câblés dans le rendez-vous
idea_ask_agent ⇄ idea_reply.

Build workspace vert, suite complète verte, zéro warning.
Backstop NON prouvé levé en live : merge develop interdit tant que la levée
du wedge n'est pas validée en conditions réelles.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-23 19:50:58 +02:00
2ef5628c72 merge(layout): intègre la ré-attache de flux au réveil arrière-plan d'un agent
Correctif UI autonome (surface humaine), vert (tsc 0, vitest 444 tests),
sans lien avec le chantier backend rendez-vous.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-23 13:53:14 +02:00
db19ef35f5 fix(layout): ré-attacher le flux d'une cellule au réveil arrière-plan d'un agent
Une cellule ne ré-attachait pas le flux de sortie de son agent lorsque
celui-ci était réveillé en arrière-plan par une délégation : l'utilisateur
devait basculer la vue Plain↔agent pour voir l'agent travailler.

Ajout d'un effect de ré-attache déclenché sur le réveil arrière-plan + bump
de la key pour forcer le remontage de la vue. Test de régression
liveReattachOnDelegation : rouge sans le fix, vert avec.

Vérifs : tsc --noEmit exit 0 ; vitest run 48 fichiers / 444 tests OK.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-23 13:52:25 +02:00
77e62e54c1 merge(orchestrator): intègre le durcissement rendez-vous inter-agents + backstop no-reply (Finding A)
Validation e2e live VERTE sur AppImage 0.3.0 :
- chemin positif (délégation pong → idea_reply → reprise, live-state working→done, aucun Busy fantôme, aucun wedge)
- test adversarial (consigne de ne pas répondre refusée par l'agent ; durcissement Lot 1 robuste).
Filet Lot 2/3 = défense-en-profondeur non exercée. Tests réels verts (application 494, app-tauri 235, infrastructure 248, mcp_server 22/22).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-22 23:57:07 +02:00
c5e54935b8 feat(orchestrator): durcir le rendez-vous inter-agents + backstop no-reply (Finding A)
Corrige le wedge survenant lorsqu'un agent délégué ne rappelle pas idea_reply :
le rendez-vous ask_agent ne reste plus bloqué indéfiniment.

Lot 1 — durcissement du préambule de délégation :
- input/mod.rs : delegation_preamble renforcé (obligation explicite idea_reply).
- agent/lifecycle.rs : préambule injecté conditionné à mcp_enabled.

Lot 2 — peuplement du prompt_ready_pattern :
- agent/catalogue.rs : .with_prompt_ready_pattern("? for shortcuts") sur le
  profil Claude + tests de seed, pour calibrer la détection de grâce.

Lot 3 — backstop timeout serveur :
- mcp/jsonrpc.rs : code d'erreur typé RENDEZVOUS_NO_REPLY (-32001).
- mcp/server.rs : mapping timeout → erreur typée, with_ask_rendezvous_timeout
  promu + resolve_ask_rendezvous_timeout (configurable).
- app-tauri/state.rs : lecture env IDEA_ASK_RENDEZVOUS_TIMEOUT_MS.
- tests/mcp_server.rs mis à jour, fix d'un test input flaky.

Propagation overlay (référence des profils) :
- agent/catalogue.rs : overlay_reference_defaults + reference_index + tests.
- store/profile.rs : ReferenceBackfillProfileStore + tests.
- app-tauri/state.rs : wrap au composition root.
- exports mod.rs / lib.rs (application + infrastructure).

Tests réels verts : application 494, app-tauri 235, infrastructure 248,
mcp_server 22/22, 0 échec. Validation e2e LIVE (rebuild AppImage) en attente
avant merge vers develop.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-22 23:46:48 +02:00
47b3806d32 chore(gitignore): désuivre .ideai/conversations/ (runtime non versionné, D19-4)
Le runtime conversationnel (handoff distillé + log.jsonl transcript par paire)
est reconstruit au fil de l'eau et ne doit pas être versionné : seul
.ideai/memory/ est le store durable. Aligne le suivi git sur le design D19-4
(cf. LS8 §7 point 3). Ajoute la règle .ideai/conversations/ au .gitignore et
désuit les 16 fichiers (8 handoff.md + 8 log.jsonl) sans les supprimer du disque.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-22 22:46:42 +02:00
36be0cb396 docs(live-state): clôture programme persistance/live-state (LS8)
Documentation de clôture du programme live-state/persistance (LS1→LS7, livré @ fd7adbb) :
- docs/LS8-live-state-persistence-closure.md : référence durable (4 stores, flux
  d'injection, chemin chaud/froid, règle de frontière, points ouverts).
- ARCHITECTURE.md : §19 marqué LIVRÉ, §14.1 items 7-8 (live-state + handoff),
  §18.5 catalogue MCP de 14 outils, nouvelle §21 (cartographie de clôture).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-22 17:53:02 +02:00
fd7adbb8a0 merge(live-state): intègre LS7 (viewer humain fil-par-paire, lecture seule)
Dernier lot fonctionnel du programme live-state : viewer frontend lecture seule
consommant read_conversation_page (LS6). tsc 0, vitest 443/443. Reste LS8 (doc de clôture).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-22 17:30:51 +02:00
c19e375849 feat(frontend): viewer humain fil-par-paire en lecture seule (LS7)
Frontend pur, lecture seule, consomme read_conversation_page (LS6) ; aucun changement backend.
- adapters : conversation.ts (gateway) + conversationNormalization.ts.
- features/conversations : useConversationThread, ConversationViewer, index.
- domain (types LS7), ports (port + Gateways.conversation), adapters/index, mock (+ clé inventaire).
- features/workstate : ProjectWorkStatePanel prop onOpenConversation.
- features/projects : ProjectsView swap viewer.
- tests (QA, verts) : conversationNormalization, mock/conversationGateway,
  useConversationThread, ConversationViewer, ProjectsView.ls7. tsc 0, vitest 443/443 (+36).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-22 17:30:51 +02:00
a0fd85cd73 merge(live-state): intègre LS6 (rotation/rétention log.jsonl + lecture paginée)
Incrément backend cohérent et vert : archive segmentée hors chemin chaud,
port ConversationArchive, lecture paginée riche + commande Tauri read_conversation_page.
Tests verts domain/infrastructure/application/app-tauri. LS7 (UX React) continue sur la feature.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-22 12:58:40 +02:00
40ca3e522f feat(domain,infra,app): rotation/rétention log.jsonl + lecture paginée (LS6)
Backend uniquement (UI React repoussée à LS7) :
- domain : port ConversationArchive + structs SegmentStats/PageCursor/PageDirection/
  TurnSlice/RotationDecision/RotationThresholds, fn pures rotation_plan/clamp_page_limit
  + consts ; re-exports lib.
- infrastructure : impl ConversationArchive pour FsConversationLog (stats/rotate/page
  + helpers), archive segmentée hors chemin chaud.
- application : ReadConversationPage + DTO + ConversationArchiveProvider (conversation/paginate),
  RotateConversationLog (conversation/rotate), exports mod/lib.
- app-tauri : AppConversationArchiveProvider + wiring (state), rotation détachée dans
  launch_agent + commande read_conversation_page (commands), DTOs (dto),
  commande enregistrée (generate_handler!).
- tests (QA, verts) : conversation_log, conversation_rotate_paginate (nouveau),
  dto (module test). Pivots INV-LS6 et cohérence fold-après-rotation verts.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-22 12:58:40 +02:00
c0efdbecce merge(live-state): intègre LS5 (borne summary_md handoff + seam LLM)
Incrément cohérent et vert qui clôt le must-have perf du handoff :
borne summary_md + élision de ligne de tour, seam LLM prêt mais non activé (ADR).
Tests verts domain/infrastructure/application. LS6 (rétention/UI) et LS7 (UX) continuent sur la feature.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-22 12:29:52 +02:00
f9231422fe docs(adr): contrat futur du seam LLM de résumé de handoff (LS5)
ADR brève : borne summary_md et point d'extension LLM (non activé).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-22 12:29:44 +02:00
13a953cb05 feat(domain,infra,app): borne summary_md du handoff + durcissement seam LLM (LS5)
Clôt le must-have perf du handoff :
- domain : HANDOFF_SUMMARY_MAX_CHARS + bound_handoff_summary (helpers privés), re-export lib.
- infrastructure : TURN_LINE_MAX_CHARS + élision dans render_turn (summarizer), re-exports.
- application : borne entre fold et save (conversation/record), borne défensive
  dans resolve_handoff (agent/lifecycle) + module test.
- seam LLM prêt mais NON activé (aucun LLM câblé).
- tests (QA, verts) : conversation_log, conversation_record, agent_lifecycle.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-22 12:29:44 +02:00
8a6cf474da merge(live-state): intègre LS1→LS4 (modèle, store, auto-update, injection + outils MCP)
Incrément cohérent du programme live-state qui clôt le cold-start de coordination :
LS1 modèle+port, LS2 store FS+use cases, LS3 auto-update depuis le cycle de délégation,
LS4 injection « État du projet » bornée + outils MCP idea_workstate_read/set.
Tests verts sur domain/application/infrastructure/app-tauri. LS5+ continue sur la branche feature.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-22 08:10:25 +02:00
533a9c57f3 feat(domain,app,infra): injection « État du projet » + outils MCP workstate (LS4)
Clôt le cold-start de coordination du programme live-state :
- domain : WorkStatus::parse/label, commands ReadWorkState/SetWorkState
  (request status/intent/progress/lastDelegation), erreur UnknownWorkStatus + validate.
- application : section bornée « # État du projet » injectée au lancement
  (port LiveStateLeanProvider, InjectedLiveRow, LIVE_STATE_INJECT_MAX, resolve_live_state) ;
  LiveStateReadProvider + read_workstate/set_workstate câblés au dispatch.
- infrastructure : 2 ToolDef idea_workstate_read / idea_workstate_set (mapping,
  tool_returns_reply), compteur d'outils MCP 12→14.
- app-tauri : providers câblés, garde du nombre d'outils 12→14.
- tests (QA, verts) : domain/orchestrator, application lifecycle + orchestrator_service,
  infrastructure mcp_server, app-tauri state.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-22 08:09:57 +02:00
9d46e6cd21 feat(app): auto-update live-state depuis le cycle de délégation (LS3)
Branche la mise à jour automatique du live-state sur le cycle de
délégation de l'orchestrateur, en best-effort non bloquant.
- Trait `LiveStateProvider` (résolution par root) + champ `Option` dans
  l'`OrchestratorService`, injecté via le builder `with_live_state` ;
  `None` ⇒ aucun effet (zéro régression).
- Transitions dérivées du cycle : `ask` → entrée `Working`,
  `reply` → `Done` + `last_delegation`.
- Helpers best-effort : un échec de mise à jour du live-state ne
  transforme jamais un succès de délégation en erreur.
- `AppLiveStateProvider` + wiring côté app-tauri (provider par root).

cargo test -p application : 0 échec ; --test orchestrator_service : 55/0
(dont 4 nouveaux tests LS3) ; cargo fmt --all --check : exit 0.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 19:28:02 +02:00
18401116aa feat(infra,app): store FS live-state + use cases (LS2)
Adapter d'infrastructure et use cases applicatifs du live-state agent.
- `FsLiveStateStore` : persistance fichier avec écriture atomique
  (write-temp + rename) pour éviter tout snapshot partiel/corrompu.
- Use cases `UpdateLiveState` / `GetLiveStateLean` + DTO « lean » (vue
  allégée, bornée pour l'injection/affichage).
- Rétention bornée côté store (TTL + max_n) au-dessus des invariants
  domaine (keyed last-writer-wins, prune).
- Garde-fou versionné : `.gitignore` exclut `.ideai/live-state.json`
  (snapshot runtime reconstruit, non versionné — contrairement à
  `.ideai/memory/`).

cargo test -p infrastructure -p application : 0 échec (dont 5 tests
live_state_store) ; cargo fmt --all --check : exit 0.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 19:12:46 +02:00
9815af01b1 feat(domain): live-state agent — modèle + port (LS1)
Domaine pur du live-state des agents : `LiveState`/`LiveEntry`/`WorkStatus`.
- Fusion en keyed last-writer-wins : une entrée par clé, la plus récente
  écrase l'ancienne (ordonnancement déterministe).
- Invariants de bornes anti-dump : bornes douces (troncature) + rejet dur
  au-delà des limites, pour empêcher un agent de noyer le live-state.
- `prune` pour borner la rétention.
- Port `LiveStateStore` (lecture/écriture), sans dépendance d'infra.

9 nouveaux tests live_state (cargo test -p domain : 208 passed / 0 failed).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 19:03:19 +02:00
827d4774cd merge(skills): intègre le chantier skill-awareness dans develop
Intègre la feature « skills agent » (rebasée proprement sur develop) :
- manifeste de skills + domaine superset (SkillRef, scopes, descriptions)
- outil MCP idea_skill_read (lecture d'un skill par nom) + compteur d'outils 11→12
- brief « capacités IdeA » inconditionnel injecté dans le contexte d'agent
- note de design feature-agent-skill-awareness

Cherry-picks ciblés depuis feature/agent-skill-awareness (cold-start e93a2c1
exclu car déjà superseded ; bruit runtime exclu). QA : backend 0 échec,
front 407/407, cargo fmt --check vert.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 18:31:04 +02:00
a1078503bc docs(skill-awareness): note de design feature-agent-skill-awareness
Récupère la seule note de design de la branche feature/agent-skill-awareness
(5be8987), hors bruit runtime .ideai. Documente la conception du manifeste de
skills, de l'outil MCP idea_skill_read et du brief « capacités IdeA ».

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 18:30:47 +02:00
a9941c01d7 feat(skill-awareness): T+ — brief « capacités IdeA » inconditionnel dans le contexte d'agent
Enrichit `compose_convention_file` pour que TOUT agent neuf, de tout
projet, soit briefé sur l'ensemble des capacités IdeA — plus seulement la
délégation. Briefing à haute altitude, télégraphique, injecté à chaque
lancement (sobriété token : capacité exposée, jamais le contenu).

Les 3 capacités sont décrites sur les 2 surfaces, strictement cloisonnées :
- MCP : via les outils `idea_context_read`/`_propose`/`idea_update_context`
  (contexte projet single-writer, proposition globale enregistrée pour
  validation, pas auto-appliquée), `idea_memory_read`/`_write` (mémoire
  durable partagée), `idea_skill_read`/`idea_create_skill` (skills).
- Sans MCP : mêmes concepts via les seuls fichiers `.ideai/` (CONTEXT.md,
  memory/ + MEMORY.md, skills `.md`), aucun nom d'outil `idea_*` ne fuit.

But : un agent ne réinvente pas son propre contexte/mémoire/workflow alors
qu'IdeA les fournit déjà.

5 tests dédiés (briefing inconditionnel même à vide, honnêteté single-writer
du contexte, cloisonnement des surfaces, ordre brief-avant-persona). 1 assert
existant adapté (`..._without_skills_omits_section` : `idea_skill_read` est
désormais toujours évoqué par le brief ; l'intention reste gardée par
l'assert sur l'absence de la section `# Skills disponibles`).
`cargo test -p application` = 0 failed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 18:30:47 +02:00
faa9692fc4 fix(test): compteur d'outils MCP 11→12 (idea_skill_read) dans state.rs
QA avait mis à jour le contrat 11→12 dans infrastructure/tests/mcp_server.rs
mais une seconde assertion codée en dur subsistait dans le test duplex de
state.rs. Ajoute idea_skill_read à la liste attendue et passe le compte à 12.
Conséquence directe de T4 (skill-awareness).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 18:30:47 +02:00
11dc8d7ba3 feat(skill-awareness): T1→T5 — manifeste de skills + outil MCP idea_skill_read
Surface les skills assignés à un agent « à la MCP » : description sur l'entité
Skill (+ effective_description fallback), section « # Skills disponibles » haute
altitude dans le convention-file (mode MCP), outil read-only idea_skill_read
(résolution projet→global), use case ReadSkill (port SkillStore existant), et
câblage au composition root. Dump legacy du corps complet conservé en mode
sans-MCP (zéro régression). Rétro-compat index.json (serde default).

Tests : domain+application+infrastructure 1212 passed / 0 failed (23 ajoutés).
Reste : T6 (champ description front) + T7 (e2e après rebuild AppImage).

NB topologie : commit réalisé par l'orchestrateur car l'agent Git était
injoignable (bug de livraison cold-start) ; à faire relire/rebaser par Git.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 18:30:47 +02:00
7db444a31d merge(input): intègre le latch released anti-blocage cold-start dans develop
Race cold-start en ordre inverse (libération avant acquisition) du portail
d'écriture : latch released garantissant exactly-once. Validé QA (fmt/check
verts, 42 tests input passés).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 18:09:32 +02:00
8bb832c3b9 fix(input): latch released anti-blocage de la race cold-start en ordre inverse
Au démarrage à froid, lorsque les évènements de cycle de vie du portail
d'écriture arrivent dans l'ordre inverse (libération observée avant
l'acquisition correspondante), le latch busy restait coincé et bloquait
définitivement la médiation d'entrée. On introduit un latch `released`
qui mémorise une libération anticipée et garantit une sémantique
exactly-once : l'acquisition tardive consomme la libération déjà vue au
lieu de re-verrouiller. Couvert par 2 tests de régression.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 18:09:27 +02:00
a66881d73d merge(workstate): intègre le correctif de l'onglet Work vide dans develop
Intègre fix/work-tab-blank-page (normalisation du work-state).
QA VERT confirmé : tsc --noEmit exit 0 ; vitest 42 fichiers / 407 tests passed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 10:42:45 +02:00
3e1e5536cc fix(workstate): normalisation du work-state pour éviter l'onglet Work vide
Normalise l'état Work pour empêcher l'affichage d'un onglet Work vide.

QA VERT : tsc --noEmit exit 0 ; vitest run 42 fichiers / 407 tests passed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 10:42:41 +02:00
fb501d10e5 merge(delegation): intègre le seam TurnResolution anti-blocage idea_ask_agent dans develop
Résolution typée des délégations sur prompt-ready après grâce, vérifiée verte par Main
(domain mailbox 6/190, infra mailbox 18, input 40, mcp_server 22, tools 16,
application orchestrator_service 51, workstate 21, lib 44 ; cargo check app-tauri OK ; fmt OK).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 10:06:39 +02:00
9684b7bbec fix(delegation): résout idea_ask_agent quand la cible revient au prompt sans idea_reply
Introduit le seam TurnResolution : sur prompt-ready, après un délai de grâce,
la délégation en attente est résolue de façon typée plutôt que de rester bloquée
indéfiniment (jusquà 24h). Couvre domain (mailbox), infrastructure (mailbox/input)
et application (orchestrator/error), avec tests étendus.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 10:06:29 +02:00
6051c6f58a merge(diag): intègre l'instrumentation des blocages idea_ask_agent dans develop
Logs diag! sur le canal de délégation inter-agents (application + infrastructure
input/mailbox/mcp), vérifiés verts par Main (mcp_server 22, mailbox 14, input 35,
tools 16, orchestrator_service 49 ; cargo check app-tauri OK ; fmt OK).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 09:41:30 +02:00
e5e412bdf2 feat(diag): instrumente les blocages de délégation idea_ask_agent
Ajoute des logs diag! sans changement sémantique le long du canal de
délégation inter-agents (application/orchestrator, infrastructure
input, mailbox, mcp server & tools) pour diagnostiquer les blocages
récurrents de idea_ask_agent. Couvert par les tests existants étendus
(mcp_server, mailbox, input, tools, orchestrator_service).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 09:41:02 +02:00
61c330a54e merge(memory): intègre la récolte automatique contrôlée (Lot E1) dans develop
Intègre le cœur E1 (feat memory récolte auto contrôlée) et le fix
indépendant mcp runtime dir socket, tests E1 ciblés verts.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 02:00:22 +02:00
8c7c47c0e8 fix(mcp): fallback déterministe du runtime dir socket
`unix_runtime_dir` essaie désormais les bases candidates dans l'ordre de
priorité ($XDG_RUNTIME_DIR → $TMPDIR → /tmp) et retient la première dont
le sous-dossier `idea-mcp` existe ou peut être créé. Un
$XDG_RUNTIME_DIR positionné mais inutilisable (sandbox/CI pointant un
chemin inexistant ou en lecture seule) ne doit plus dead-end le bind
loopback : sans ce fallback le socket ne se liait jamais en silence et la
délégation inter-agents mourait. Déterministe pour un environnement donné,
donc le côté bind et tout lecteur de `socket_path()` s'accordent sur le
même répertoire.

Indépendant du Lot E1.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 02:00:13 +02:00
b12081be18 feat(memory): récolte automatique contrôlée de la mémoire (Lot E1)
Câble la récolte automatique de mémoire de bout en bout, sous contrôle
explicite, du domaine jusqu'à l'UI :

- domain : modèle `memory_harvest` (candidats de récolte, décision) +
  exports `lib.rs`.
- application : use case `memory/harvest` branché dans `memory/mod`,
  `lib.rs`, le cycle de vie d'agent (`agent/lifecycle`) et
  l'orchestrateur (`orchestrator/service`).
- app-tauri : wiring runtime dans `state`.
- frontend : DTO `domain/index` + hook `useMemory`.

Couverture : domain `memory_harvest` (14), application `memory_harvest`
(5) et `orchestrator_service` (récolte, 4), plus patch test-only du mock
gateway `workState` (`mock.test.ts`) et UI `memory.test`.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 02:00:05 +02:00
33e65dec74 chore(wip): état runtime .ideai + mémoire (checkpoint Lot D actions contrôlées)
Conversations live, MEMORY.md et note checkpoint
workstate-controlled-actions-lot-d.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 19:54:45 +02:00
c1e99d13a7 merge(workstate): intègre les actions contrôlées (Lot D) dans develop
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 19:52:00 +02:00
0976648d4c chore(wip): état runtime .ideai (flux conversation live)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 19:51:57 +02:00
1c6441bb35 feat(workstate): UI des actions contrôlées (Lot D frontend)
Câble les actions contrôlées dans ProjectWorkStatePanel : port et adaptateur
agent étendus aux nouvelles commandes, adaptateur mock aligné.

Tests verts : workstate + projects (25), agent (8), singletonAgent +
agentAlreadyRunning (9), tsc --noEmit OK.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 19:51:52 +02:00
3408c96974 feat(workstate): actions contrôlées sur le work-state (Lot D backend)
Ajoute un module d'actions contrôlées (`workstate/actions.rs`) côté application
et l'expose via des commandes Tauri : DTO camelCase, câblage commands/state/lib.
Les actions valident leurs invariants avant d'agir sur le read-model.

- application : use cases d'actions contrôlées + intégration au work-state.
- app-tauri : commandes dédiées, DTO et enregistrement dans le handler.

Tests verts : application workstate_actions (7), workstate (21),
app-tauri dto_agents (25), list_live_agents_r0b (5), cargo check OK.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 19:51:46 +02:00
7c71544692 chore(wip): état runtime .ideai + mémoire (checkpoint Lot C résumés conversation)
Conversations live, layouts, MEMORY.md et note checkpoint
workstate-conversation-summaries-lot-c.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 19:32:18 +02:00
6e1ba7ee58 merge(workstate): intègre les résumés de conversation (Lot C) dans develop
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 19:29:10 +02:00
78500d81c1 chore(wip): état runtime .ideai (flux conversation live)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 19:29:05 +02:00
c50622e944 feat(workstate): UI des résumés de conversation (Lot C frontend)
Affiche les résumés de conversation dans ProjectWorkStatePanel à partir du
DTO camelCase : type de domaine et adaptateur mock alignés, panneau enrichi.

Tests verts : workstate.test.tsx + projects.test.tsx (2 fichiers / 19),
tsc --noEmit OK.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 19:29:01 +02:00
e9edadca50 feat(workstate): résumés de conversation dans le read-model (Lot C backend)
Étend le read-model work-state pour exposer un résumé par conversation
(participants, dernier message/activité, compteurs) câblé jusqu'au DTO
camelCase de l'état app-tauri.

- application : assemblage des résumés de conversation dans le work-state.
- app-tauri : DTO camelCase des résumés + exposition dans l'état.

Tests verts : application workstate (21), app-tauri dto_agents (21),
aucun warning Rust.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 19:28:55 +02:00
e5dd4f82f5 chore(wip): état runtime .ideai + mémoire (checkpoint Lot B délégations/file)
Conversations live, MEMORY.md et note checkpoint
workstate-delegation-queue-lot-b.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 19:08:06 +02:00
64c2c14780 merge(workstate): intègre le snapshot délégations/file par agent (Lot B) dans develop
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 18:52:34 +02:00
5cb99fd353 chore(wip): état runtime .ideai (flux conversation live, layouts)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 18:52:27 +02:00
c60060494d feat(workstate): UI des délégations en file par agent (Lot B frontend)
Affiche les tickets en attente dans `ProjectWorkStatePanel` à partir du
snapshot de file exposé par le read-model : type de domaine et adaptateur
mock alignés sur le DTO `camelCase`, panneau enrichi (requester, aperçu de
tâche, position FIFO), hook de lecture mis à jour.

Tests verts : workstate.test.tsx + projects.test.tsx (2 fichiers / 17),
`tsc --noEmit` OK.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 18:52:23 +02:00
cc7d99a63e feat(workstate): snapshot des délégations en file par agent (Lot B backend)
Ajoute un port de lecture ségrégué `AgentQueueSnapshot` (ISP) distinct du
`AgentMailbox` mutant : il expose `queue_for(agent)` qui renvoie des
`QueuedTicketSnapshot` clonés, ordonnés FIFO, avec position recalculée
(0 = tête). Observer la file ne la mute jamais ; le one-shot reply sender
reste dans l'adaptateur.

- domain : value object `QueuedTicketSnapshot` + trait `AgentQueueSnapshot`
  (object-safe, partagé en `Arc<dyn …>`).
- infrastructure : `InMemoryMailbox` implémente la vue lecture en plus de la
  vue mutation ; positions recalculées à chaque appel.
- application : le read-model work-state liste les délégations en attente via
  ce port, troncature de l'aperçu de tâche en conservant la longueur d'origine.
- app-tauri : DTO `camelCase` des tickets en file câblé dans l'état.

Tests verts : domain mailbox (6), infrastructure mailbox (13),
application workstate (12), app-tauri dto_agents (20).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 18:52:16 +02:00
7453181e6c chore(wip): état runtime .ideai (flux conversation live)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 18:10:48 +02:00
3bfb932f13 merge(workstate): intègre le read-model live-state + UX conversations (Lot A) dans develop
Lot A : read-model live-state minimal des conversations/délégations côté backend
(module application workstate + surface Tauri) et frontend (port/adapter/mock +
feature workstate intégrée à ProjectsView).

QA verte, réserve environnementale non bloquante (socket Unix non bindable en
sandbox, alternatives skips vertes).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 18:06:48 +02:00
a06328a5bc chore(wip): état runtime .ideai (conversations live, agents, layouts)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 18:06:33 +02:00
17685a08e1 feat(workstate): UI live-state des conversations/délégations (Lot A frontend)
Ajoute le port et l'adaptateur workState (+ mock) côté frontend, le type domaine
associé, et la feature `workstate` (panneau ProjectWorkStatePanel + hook
useProjectWorkState) consommant le read-model live exposé par le backend.
Intègre le panneau dans ProjectsView. Tests verts (workstate + projects).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 18:06:28 +02:00
aae18499a9 feat(workstate): read-model live-state minimal des conversations/délégations (Lot A backend)
Introduit le module application `workstate` (modèle de read-model live + snapshots
des conversations/délégations en cours) et l'expose via la couche terminal
(exports mod/registry). Câble la surface Tauri : DTO, commande et state pour
exposer le live-state au frontend (lib + state + commands), avec tests.

QA verte. Réserve environnementale non bloquante : tests loopback socket Unix
réels non exécutables en sandbox (UnixListener::bind PermissionDenied),
alternatives avec skips vertes.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 18:06:22 +02:00
6cfa0b04c6 chore(wip): état runtime .ideai (flux conversation live)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 11:10:21 +02:00
338051e163 chore(wip): état runtime .ideai (flux conversation live)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 11:07:53 +02:00
63eb49aa5e merge(skills): intègre agent-skill-awareness-v2 dans develop
Awareness skills dans le fichier de convention (feat befff76), hotfix livraison
délégation + logs submit (fix 018eb1a) et état runtime associé.

QA vert accepté avec réserve environnementale : tests loopback socket Unix réels
non exécutables en sandbox (UnixListener::bind PermissionDenied), alternatives
avec skips vertes.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 10:58:19 +02:00
8074aec16c chore(wip): état runtime .ideai (flux conversation live)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 10:58:10 +02:00
cc575efe27 chore(wip): état runtime .ideai (conversations, layouts, mémoire, checkpoint skill-awareness)
Mise à jour de l'état runtime non-code : flux de conversations (handoff/log.jsonl),
layouts, index mémoire MEMORY.md, et nouveau checkpoint
checkpoint-delivery-submit-logging-fix.md.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 10:57:24 +02:00
018eb1a25e fix(input): fiabilise la livraison de délégation et journalise le submit
Durcit le portail d'écriture de délégation et son acheminement bout-en-bout
(commande Tauri → orchestrateur → file d'entrée infrastructure → portail
frontend), avec une journalisation du submit pour diagnostiquer les cas où la
délégation n'était pas remise. Couvre le portail d'écriture côté front
(useWritePortal) avec ses tests.

QA : checks application/front/infrastructure/app-tauri verts. Les tests loopback
socket Unix réels ne sont pas exécutables en sandbox (UnixListener::bind →
PermissionDenied) ; alternatives avec skips vertes.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 10:57:20 +02:00
befff76de8 feat(skills): injecte un paragraphe d'awareness skills dans le fichier de convention
compose_convention_file émet désormais, dans le bloc d'orchestration (avant le
contexte projet et la persona), un court paragraphe expliquant qu'un skill
assigné est du contexte opérationnel — ni commande magique, ni sous-tâche
fournisseur — et oriente la capitalisation de workflows réutilisables vers la
surface d'orchestration active : `idea_create_skill` en profil MCP, le protocole
fichier `skill.create` sinon.

L'awareness n'injecte volontairement pas le corps des skills non assignés :
l'assignation reste la frontière de contexte. Tests de composition (présence,
ordre root → orchestration → contexte → persona, branche MCP vs fichier) verts.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 10:57:11 +02:00
e832af5428 chore(wip): état runtime .ideai (conversations, layouts, mémoire, checkpoint blocage AppImage 0.3.0)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 09:12:01 +02:00
9c71a5bd40 chore(wip): état runtime .ideai post-build AppImage 0.3.0
Persiste la dérive runtime après rebuild de l'AppImage 0.3.0 (conversation
6bc594e8 handoff+log, layouts) et ajoute le checkpoint
checkpoint-orchestrator-designation-appimage-build (build via appimagetool
--runtime-file en contournement de l'échec linuxdeploy), indexé dans MEMORY.md.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 09:01:15 +02:00
55d887fc78 merge(orchestrator): intègre le chantier orchestrator-designation dans develop
Modèle de désignation d'orchestrateur (AgentManifest + may_write_directly),
sink de diagnostic du rendez-vous inter-agents, et durcissement du portail
d'écriture de délégation côté frontend.

QA verte : application (suite complète + orchestrator_service 45), infrastructure
input (35), frontend vitest (384) et tsc. Résidu qualifié : 8 tests e2e app-tauri
qui bindent un vrai socket Unix échouent en EPERM — contrainte sandbox
d'environnement (reproduite avec une sonde Node minimale), pas un défaut du code.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 08:56:47 +02:00
5ef001e7a3 chore(wip): état runtime .ideai (conversations, layouts, mémoire, checkpoints)
Persiste l'état runtime : manifestes agents, layouts, permissions, logs et
handoffs de conversations, index mémoire et checkpoints du chantier
orchestrator-designation (restart, backend-compile-fix, qa-verdict) ainsi que
la note conversation-rotation-safety-design.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 08:56:40 +02:00
09f536289b docs: resynchronise CLAUDE.md (rôle, méthode, cycle, vision)
Met à jour le document de méthode du projet (rôle de chef d'orchestre,
boucle de dev Architect→Git→Dev→QA, agent Git propriétaire de la topologie,
vision produit et stack).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 08:56:40 +02:00
e462136df2 feat(terminals): durcit le portail d'écriture de délégation
Fiabilise la livraison des délégations inter-agents dans le terminal :
écriture par chunks UTF-8 bornés (512 o, délai 8 ms) pour éviter les
comportements de paste/drop des TUI sur agents froids, et réconciliation
de l'attachement front (frontAttachedAgentRef / reconcileFrontAttachment)
pour ne reporter « front attaché » qu'une fois les DelegationReady
réellement consommés. Tests vitest associés.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 08:56:39 +02:00
287681c198 feat(orchestrator): modèle de désignation d'orchestrateur + sink de diagnostic
Introduit le modèle AgentManifest { version, entries, orchestrator } et la
garde d'écriture directe may_write_directly(..., &OrchestratorDesignation) :
seul l'orchestrateur désigné peut écrire directement, les autres passent par
le rendez-vous médié. Câble la désignation à travers domain → application →
infrastructure → app-tauri (context_guard, service, lifecycle, ports).

Ajoute crates/application/src/diag.rs : sink de diagnostic best-effort, sans
dépendance, qui miroite les traces du rendez-vous inter-agents de
l'orchestrateur vers un fichier de log persistant (utile au lancement via
AppImage où stderr est jeté), avec la même discipline « zéro dépendance,
ne casse jamais le rendez-vous ».

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 08:56:39 +02:00
40982d44da chore(release): passe la version à 0.3.0
Bump des 4 crates du workspace (domain, infrastructure, application,
app-tauri), de tauri.conf.json, du package.json frontend et des entrées
correspondantes de Cargo.lock. Prépare l'intégration de develop dans main.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-20 08:38:05 +02:00
845233377e merge(orchestrator): intègre le câblage du ContextGuard dans develop
Correctif fix/wire-context-guard : branchement .with_context_guard(...)
au composition root + re-exports application + 3 tests de non-régression.
Tests QA verts (cargo test -p app-tauri : 0 failed).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-17 13:36:29 +02:00
181727d851 fix(orchestrator): câble le ContextGuard au composition root
Le composition root (app-tauri/state.rs) n'appelait pas
.with_context_guard(...) : les outils MCP de contexte/mémoire
(idea_context_read/propose, idea_memory_read/write) n'étaient
donc pas réellement branchés au runtime, alors que le use case
existait côté application.

- application: re-export public de ContextGuardUseCases (orchestrator/mod.rs)
  et de ContextGuardUseCases, ReadContext, ProposeContext, ReadMemory,
  WriteMemory (lib.rs), pour que app-tauri puisse les câbler.
- app-tauri: branchement .with_context_guard(...) au composition root
  + 3 tests de non-régression (round-trip memory read/write, context read,
  symétrie d'erreur typée) dans mcp_serve_peer_tests.

Tests QA verts : cargo test -p app-tauri (0 failed), build 0 warning.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-17 13:36:22 +02:00
6969dc7988 chore(wip): état runtime .ideai (conversations, layouts, mémoire, skills)
Snapshot de l'état runtime accumulé sur develop : logs/handoffs de
conversations, layouts, notes mémoire (dont git-owns-commit-merge-decisions)
et catalogue de skills.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-17 09:14:01 +02:00
ba56be6951 chore(release): passe la version à 0.2.0
Bump des manifestes (crates Rust + frontend) et des lockfiles vers
0.2.0 en préparation de la release. Ajoute /node_modules à .gitignore
(tooling installé à la racine, jamais versionné).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-17 09:13:53 +02:00
d7041c53ce merge(session-limits): intégration de la feature limites de session (3 niveaux)
Intègre feature/agent-session-limits dans develop. Surface complète :
- Niveau 1 : tap de détection sur agent_send (limites remontées par la CLI).
- Niveau 2 : détecteur déclaratif au lancement (parser regex confiné) +
  reprise automatique planifiée (TokioScheduler) et annulable.
- Niveau 3 : filet humain (set_resume_at / saisie d'heure) quand l'heure
  n'est pas exploitable automatiquement.
Backend (domain/application/app-tauri) + front (badge, compte à rebours,
formulaire de reprise) ; suites Rust et front vertes.

Commits : LS2..LS8 (a1755e53f3504e).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-17 08:45:39 +02:00
3f3504efa3 fix(test): corrige le compteur de gateways du mock (13 → 14)
Le test asseyait « thirteen gateways » alors que la gateway permission
(présente depuis eca2ba9) en porte le total à 14. Compteur périmé sans
rapport avec session-limits, corrigé isolément avant le merge d'intégration.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-17 08:45:00 +02:00
5d9dd32c29 feat(session-limits): LS8-front — filet humain niveau 3 (saisie d'heure de reprise)
UI permettant à l'humain de renseigner l'heure de reprise quand le
niveau 2 détecte une limite sans heure exploitable.

- ports/index.ts : setResumeAt(agentId, resetsAtMs) sur InputGateway.
- adapters/input.ts : setResumeAt → invoke("set_resume_at").
- adapters/mock/index.ts : MockInputGateway.setResumeAt (resumeArmings[]).
- features/agents/useAgents.ts : action setResumeAt (sans mutation optimiste).
- features/agents/AgentLimitBadge.tsx : formulaire de saisie d'heure sur
  l'état suspected sans heure + helper pur timeInputToEpochMs (TODO LS7 retiré).
- features/agents/AgentsPanel.tsx : câblage onSetResumeAt.

Tests AgentLimitBadge.test.tsx mis à jour au nouveau contrat + couverture LS8 ;
typecheck propre, suite agents verte.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-17 08:44:54 +02:00
c480d2820a feat(session-limits): LS8-backend — filet humain niveau 3 (set_resume_at)
Permet à l'humain de confirmer/forcer l'heure de reprise quand le
niveau 2 a détecté une limite sans heure exploitable.

- application/agent/session_limit.rs : refactor privé arm_scheduled
  (param resets_at_ms brut) partagé par on_rate_limited + nouvelle
  confirm_human_resume(agent_id, node_id, conversation_id, resets_at_ms)
  (source Human, réutilise la branche Scheduled, annulable).
- app-tauri/commands.rs : commande set_resume_at(agent_id, resets_at_ms)
  (résout node_id via node_for_agent + conversation_id best-effort,
  NOT_FOUND si pas de cellule vivante).
- app-tauri/lib.rs : set_resume_at enregistrée après cancel_resume.

Réutilise les événements existants (AgentRateLimited + AgentResumeScheduled),
aucun nouvel événement. Tests : +6 session_limit_service, +2 wiring, verts.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-17 08:44:45 +02:00
4fad0423e7 feat(session-limits): LS7-front — UI limites de session (badge + compte à rebours + filet humain)
Expose la surface produit des limites de session côté React/TS,
au-dessus du câblage backend (9df5923).

- domain/index.ts : 5 variantes ajoutées au union DomainEvent
  (agentRateLimited / ResumeScheduled / ResumeCancelled / Resumed /
  RateLimitSuspected).
- ports/index.ts : cancelResume(agentId) ajouté à InputGateway.
- adapters/input.ts : TauriInputGateway.cancelResume → invoke("cancel_resume").
- adapters/mock/index.ts : MockInputGateway.cancelResume
  (cancelledResumes / cancelResumeResult).
- features/agents/useAgents.ts : état limitByAgent + action cancelResume.
- features/agents/AgentLimitBadge.tsx (nouveau) : badge + compte à rebours
  + bouton Annuler + helpers purs.
- features/agents/AgentsPanel.tsx : câblage du badge.

Tests : useAgentsLimits.test.tsx (13) + AgentLimitBadge.test.tsx (11),
suite agents 63 tests verts, tsc --noEmit propre.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-17 08:06:56 +02:00
9df592389c feat(session-limits): LS7 — câblage backend app-tauri (taps niveaux 1&2 + reprise annulable)
Branche le SessionLimitService dans l'application Tauri et expose la
surface de reprise/annulation au front.

- application/agent/lifecycle.rs : LaunchAgentOutput.profile exposé
  (None sur réattache/idempotent, Some sur lancement effectif).
- application/terminal/registry.rs : StructuredSessions::meta_for_session()
  (lookup agent/node par SessionId pour le tap niveau 1).
- app-tauri/state.rs : ResumeContext(s), AppAgentResumer (impl du port
  AgentResumer au-dessus de LaunchAgent), instanciation + câblage du
  SessionLimitService (TokioScheduler + drain des réveils) dans AppState::build.
- app-tauri/commands.rs : taps niveau 1 (agent_send) et niveau 2
  (launch_agent, parser regex confiné), alimentation de resume_contexts,
  commande cancel_resume.
- app-tauri/lib.rs : enregistrement de cancel_resume dans le handler.
- app-tauri/Cargo.toml : dépendance async-trait.

Tests : session_limit_wiring.rs (2 tests de composition) + meta_for_session
dans structured_registry_d1.rs ; fixtures dto_agents/dto_chat ajustées
(profile: None). Tout vert.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-17 07:56:08 +02:00
ea94e756e2 feat(session-limits): LS6 — câblage des événements de limite vers le front
Relaie les 5 nouvelles variantes DomainEvent (AgentRateLimited, ResumeScheduled,
ResumeCancelled, Resumed, RateLimitSuspected) via leurs DTO miroirs et bras From
dans events.rs, et propage ReplyEvent::RateLimited en chunk côté chat.rs pour que
le front soit informé des suspensions/reprises de session.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 20:02:29 +02:00
98bfcf4f22 feat(session-limits): LS5 — détecteur niveau 2 déclaratif + parsing temps partagé
Ajoute un détecteur niveau 2 (RateLimitParser, regex confiné à l'infra) qui
repère les mentions de limite de session dans la sortie textuelle, et factorise
le parsing d'heures dans un module pur (timeparse) partagé entre les niveaux 1
et 2. Le détecteur Claude niveau 1 est refactoré vers timeparse (~-121 lignes).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 20:02:24 +02:00
9000b4d09f feat(session-limits): LS4 — service application + réconciliation T4
Orchestre la détection et la reprise au niveau application :
- session_limit.rs (nouveau) : SessionLimitService + port AgentResumer +
  const RESUME_PROMPT.
- structured.rs : réconciliation T4 — enum TurnOutcome +
  drain_with_readiness_outcome ; signatures historiques préservées.
- agent/mod.rs + lib.rs : modules et re-exports.

Tests QA (nouveaux) : tests/session_limit_service.rs (9) +
tests/session_limit_t4.rs (7).
`cargo test -p application` = tous binaires verts / 0 failed (16 nouveaux),
zéro régression (drain_with_readiness_lot1 7/7, send_blocking_d1 9/9) ;
builds domaine+infra+application 0 warning.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 18:55:26 +02:00
253310bb3e feat(session-limits): LS3 — port Scheduler + adapter TokioScheduler
Introduit l'abstraction de planification pour la reprise différée à la
levée d'une limite de session :
- domaine : trait Scheduler + enum ScheduledTask (ports.rs), ScheduleId
  via typed_id! (ids.rs), re-exports (lib.rs).
- infra : TokioScheduler (scheduler/mod.rs, nouveau) + pub mod scheduler
  et re-export (lib.rs).

Tests QA inline (#[cfg(test)]) : 7 tests scheduler (3× sans flaky).
`cargo test -p infrastructure` = 195 passed / 0 failed ; domaine + infra
builds 0 warning ; LS1/LS2 toujours verts.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 15:07:48 +02:00
a1755e51bc feat(session-limits): LS2 — adapter Claude niveau 1 (infra)
Câble la détection de limite de session dans l'adapter Claude :
- claude.rs : parse_event émet ReplyEvent::RateLimited ; nouvelle fonction
  pure parse_reset_ms + helpers ; parseur ISO maison ; doccomments T4.
- mod.rs : 26 nouveaux tests QA (#[cfg(test)]) + 2 tests existants alignés
  sur le nouveau contrat.
- conformance.rs : RateLimited ajouté aux événements non terminaux autorisés.

`cargo test -p infrastructure` = 188 passed / 0 failed, zéro régression.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 14:44:53 +02:00
0bf1eb3b11 feat(session-limits): LS1 — couche domaine (détection + plan de reprise)
Pose les briques pures du domaine pour la gestion des limites de session
des agents (état en mémoire, aucun schéma de persistance modifié) :
- session_limit.rs (nouveau) : SessionLimit, ResumePlan, RateLimitSource,
  plan_resume (calcul du plan de reprise annulable).
- ports.rs : variante ReplyEvent::RateLimited.
- readiness.rs : variante ReadinessSignal::RateLimited + classify.
- profile.rs : RateLimitPattern + champ + builder.
- events.rs : 5 variantes DomainEvent pour le cycle de vie limite/reprise.
- lib.rs : module + re-exports.

Tests QA inline (#[cfg(test)]) : 24 tests dédiés.
`cargo test -p domain` = 165 passed / 0 failed, zéro régression.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 14:33:57 +02:00
fa5b826df5 docs(session-limits): cadrage Architect — gestion des limites de session des agents
Pose le cadrage de la feature « Gestion des limites de session des agents »
avant tout code (lots LS1→LS8) :
- ARCHITECTURE.md §21 : détection hiérarchique des limites de session +
  reprise auto annulable (domaine → adapter Claude → port Scheduler →
  service → parser regex → filet humain → app-tauri → frontend) ; état en
  mémoire uniquement, aucun schéma de persistance modifié.
- .ideai/memory/session-limit-handling-design.md : design validé.
- .ideai/memory/MEMORY.md : pointeur vers le design.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 14:25:05 +02:00
401c18ad3c chore(repo): retire les gitlinks de worktree .claude/ committés par accident
Deux entrées gitlink (mode 160000) pointant vers des commits de worktrees
agent locaux avaient été versionnées par erreur. Elles sont déjà couvertes
par .gitignore (.claude/worktrees/) ; on les sort simplement du suivi.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 14:01:19 +02:00
a04fbb7e1c merge(develop): intègre permissions/sandbox OS + pont Codex inter-agents
Intègre dans develop le travail terminé et testé porté par
wip/p8c-checkpoint-before-codex :
- enforcement OS des permissions (Landlock) bout-en-bout (LP4-0→LP4-4)
- pont Codex inter-agents + readiness/heartbeat
- layouts UI responsive + setup agent Git
Tests crates cœur (domain/application/infrastructure) verts.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 13:56:34 +02:00
69304b0f6b chore(wip): état runtime .ideai (agents.json, layouts.json)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 13:56:06 +02:00
64ab3835c7 docs(agents): introduit l'agent Git (contexte + intégration au cycle)
Ajoute le contexte de l'agent Git (.ideai/agents/git.md) garant du dépôt
git local (commits, branches, merges/rebases) et l'inscrit dans le cycle
de dev de CLAUDE.md (§2.4 + étape « décide de la branche » / « merge
éventuel feature/* → develop »). Formalise le modèle main ← develop ←
feature/*.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 13:56:06 +02:00
00bda6a988 chore(wip): état runtime .ideai (conversations, agents, layouts)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 09:39:07 +02:00
31b636037d fix(ui): layouts responsive pour panneau agents et bandeau d'onglets sidebar
AgentsPanel : formulaire de création et items d'agent passent en colonne,
les libellés/états longs (running in IdeA, profil) wrappent/tronquent au lieu
de déborder. ProjectsView : les onglets de la sidebar wrappent sur plusieurs
lignes pour rester tous visibles, le bouton collapse reste épinglé en haut.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 09:39:03 +02:00
40bce5c8bf feat(sandbox): Landlock no-op sous Posture::Allow (allow-by-default)
Un allowlist Landlock ne peut que retirer des accès (deny-by-default). Sous
une fallback Posture::Allow (allow-by-default), enforcer les grants
verrouillerait tout hors du project root — binaire CLI, libs et ~/.<cli> —
provoquant le 'failed to open terminal'. On n'enforce donc rien sous Allow ;
seuls les Deny explicites font foi (advisory via la projection LP3).
Couvre permissions.json persisté avec fallback allow.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 09:38:57 +02:00
ab9162f686 docs(memory): consigne l'etat du systeme de permissions/sandbox + risque residuel $HOME
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 08:51:57 +02:00
6236cd727b feat(permissions): LP4-4 — enforcement Landlock sur le chemin structuré
Étend l'enforcement OS au chemin structuré (sessions Claude/Codex mode JSON),
jusqu'ici seulement advisory. Approche validée par l'Architecte : transposer la
technique du PTY plutôt qu'un pre_exec (rejeté — landlock alloue, deadlock malloc
post-fork en process multithreadé).

Mécanique (cfg(target_os=linux)) : run_turn_sandboxed/drain_sandboxed exécutent
enforce(plan) sur un thread jetable AVANT le spawn std, puis std::process::spawn
depuis ce thread ; l'enfant hérite le domaine Landlock via les credentials de la
tâche (garanti à travers fork/clone/execve, y compris posix_spawn — pas de pre_exec
nécessaire, forbid(unsafe_code) préservé). Fail-closed sur Err d'enforce (aucun
child). Timeout sous sandbox : oneshot killer + tokio::time::timeout → kill → EOF →
reap (pas de zombie/thread bloqué). Chemin non-sandboxé (plan None / pas d'enforcer /
non-Linux) = drain async tokio inchangé.

Contrat : SpawnLine.sandbox ; AgentSessionFactory::start(.., sandbox) ;
StructuredSessionFactory::with_sandbox_enforcer (jumeau du PTY) ; plan calculé en
step 5d de lifecycle relayé à launch_structured ; default_enforcer() injecté au
composition root.

Tests : 7 invariants e2e (parité, companion négatif, fail-closed, no-op natif,
confinement de l'irréversibilité entre tours, timeout, resume préservé) — zéro
token (sh/FakeCli). 80 suites vertes, 0 failed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 08:47:33 +02:00
7e01ac60cb feat(permissions): LP4-3 — activation bout-en-bout de la sandbox OS au runtime
Composition root : PortablePtyAdapter::new() injecte désormais default_enforcer()
(Landlock sur Linux / Noop ailleurs) via with_sandbox_enforcer, dans state.rs et
dans LocalHost (remote/mod.rs).

Launch path : LaunchAgent::execute peuple spec.sandbox via le plan pur
compile_sandbox_plan(effective_permissions, SandboxContext{project_root, run_dir}),
en réutilisant l'EffectivePermissions déjà résolu pour la projection advisory LP3.
Invariant produit conservé : eff == None ⇒ plan None ⇒ comportement natif, aucune
projection OS.

Portée : seul le chemin PTY brut est OS-enforcé ; le chemin structuré (Claude/Codex
mode JSON) porte le plan mais ne l'enforce pas encore (lot ultérieur).

Tests : ajout d'un test d'intégration bout-en-bout (pty/mod.rs, sandbox_e2e_tests)
prouvant qu'un enfant spawné sous un plan RW restreint ne peut PAS écrire hors-grant
(écriture bloquée par le kernel) alors que l'écriture dans le grant passe, plus un
test compagnon anti faux-positif (sans plan ⇒ pas de sandbox). Skip propre si le
kernel n'a pas Landlock. domain+infrastructure+application+app-tauri verts.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 08:08:40 +02:00
17ca65ed0f feat(permissions): LP4-1/LP4-2 — enforcer Landlock OS + consommation PTY du plan
LP4-1 : adaptateurs SandboxEnforcer concrets (LandlockSandbox Linux via le LSM
Landlock, NoopSandbox ailleurs) + default_enforcer() cfg-sélectionné, prêts à
être injectés au composition root (LP4-3). Aucun changement de comportement
runtime tant que rien n'est câblé : SpawnSpec.sandbox reste None.

LP4-2 : PortablePtyAdapter consomme SpawnSpec.sandbox via spawn_command_sandboxed
(thread jetable restreint par enforce() puis fork → le domaine Landlock est hérité
par l'enfant à travers execve ; les autres threads d'IdeA ne sont jamais sandboxés).
Builder additif with_sandbox_enforcer ; fail-closed si enforce() échoue.

Tests : domain + infrastructure verts (dont les tests Landlock réels de fencing
read-only/write-only et la confine-au-thread).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 08:00:47 +02:00
476 changed files with 70839 additions and 3534 deletions

Submodule .claude/worktrees/agent-a2650e91d2bd39ca2 deleted from 480e7c7bbe

Submodule .claude/worktrees/agent-aeb1e862ef04b991b deleted from ef101db9dc

15
.gitignore vendored
View File

@ -1,12 +1,16 @@
# ─── Rust / Cargo ───────────────────────────────────────────────────────────
# Build output for the whole workspace (Cargo.lock IS committed — it's an app).
/target/
# ...et les target/ des sous-crates du workspace (règle non ancrée).
target/
**/*.rs.bk
# ─── Node / frontend ────────────────────────────────────────────────────────
# Dependencies and build output (package-lock.json IS committed).
frontend/node_modules/
frontend/dist/
# Root-level node_modules (dev tooling installs at repo root — never versioned).
/node_modules/
# npm/yarn/pnpm debug logs
npm-debug.log*
yarn-debug.log*
@ -38,6 +42,12 @@ frontend/coverage/
# Runtime file-protocol orchestration requests/responses — transient I/O, not
# durable project state (curation .ideai §chantier secondaire).
.ideai/requests/
# 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/).
.ideai/live-state.json
# 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).
/.ideai/layouts.json
# ─── Editors / OS ───────────────────────────────────────────────────────────
.idea/
@ -47,3 +57,8 @@ frontend/coverage/
*~
.DS_Store
Thumbs.db
# Conversation runtime (handoff distillé + log.jsonl transcript par paire) :
# état d'exécution reconstruit au fil de l'eau — not versioned (LS8 §7, design D19-4 ;
# seul .ideai/memory/ est le store durable versionné).
.ideai/conversations/
.ideai/agents.json

View File

@ -1,54 +0,0 @@
{
"version": 1,
"agents": [
{
"agentId": "a6ced819-b893-4213-b003-9e9dc79b9641",
"name": "Main",
"mdPath": "agents/main.md",
"profileId": "664cc20c-47b8-53ad-9351-dce3c09c0de4",
"synchronized": false
},
{
"agentId": "dce19c75-9669-4e45-b8de-9950025157da",
"name": "Architect",
"mdPath": "agents/architect.md",
"profileId": "664cc20c-47b8-53ad-9351-dce3c09c0de4",
"synchronized": false
},
{
"agentId": "73c853d1-c0fd-463b-ad17-1d24fefa371f",
"name": "DevBackend",
"mdPath": "agents/devbackend.md",
"profileId": "664cc20c-47b8-53ad-9351-dce3c09c0de4",
"synchronized": false
},
{
"agentId": "af7f86da-76bc-48e1-9900-71f45a624800",
"name": "DevFrontend",
"mdPath": "agents/devfrontend.md",
"profileId": "664cc20c-47b8-53ad-9351-dce3c09c0de4",
"synchronized": false
},
{
"agentId": "aefdbd61-e3d4-4bc1-9f42-c259446a97b5",
"name": "QA",
"mdPath": "agents/qa.md",
"profileId": "664cc20c-47b8-53ad-9351-dce3c09c0de4",
"synchronized": false
},
{
"agentId": "c932c770-cf36-4fb2-a966-71bb1644e4b4",
"name": "TestConversation",
"mdPath": "agents/testconversation.md",
"profileId": "664cc20c-47b8-53ad-9351-dce3c09c0de4",
"synchronized": false
},
{
"agentId": "484eff91-60a1-459f-9ebe-c9552cc70447",
"name": "NewTest",
"mdPath": "agents/newtest.md",
"profileId": "664cc20c-47b8-53ad-9351-dce3c09c0de4",
"synchronized": false
}
]
}

View File

View File

@ -51,9 +51,10 @@ Le workspace Cargo multi-crate, sens des dépendances **strict** (`Présentation
## 5. Délégation & collaboration
- Pour déléguer/discuter avec un autre agent, tu utilises **le protocole d'orchestration IdeA**
(`.ideai/requests/<ton-agent>/`), **jamais** les subagents natifs du fournisseur. *(Tant que
l'orchestration v3 n'est pas livrée, Main relaie manuellement.)*
- Pour déléguer/discuter avec un autre agent, utilise le mécanisme IdeA indiqué dans le
contexte applicatif injecté : `idea_ask_agent(target, task)` si l'outil MCP est
disponible, sinon le fallback `.ideai/requests/<ton-agent>/`. Quand tu es sollicité,
réponds normalement en fin de tour ; IdeA capture ta réponse finale.
- Ta source de vérité d'architecture est `architect.md`. En cas de contradiction entre ton code
et ce document, c'est le document qui gagne — ou tu remontes l'incohérence à Main.

View File

@ -2,7 +2,8 @@
> Tu es l'**agent de développement frontend** d'IdeA. Tu écris l'UI **TypeScript + React**.
> Tu respectes **strictement** la cartographie d'`Architect` (`.ideai/agents/architect.md`) et
> l'hexagonal **côté frontend aussi**. Tu es appairé à l'agent **QA** : aucune feature n'est
> l'hexagonal **côté frontend aussi**. Tu implémentes l'UI selon les **specs de design de `UX`**
> (`.ideai/agents/ux.md`). Tu es appairé à l'agent **QA** : aucune feature n'est
> finie tant que ses tests (`vitest`) ne sont pas verts.
---
@ -20,18 +21,26 @@ qu'à des **gateways (ports TS)**, jamais directement à l'IPC Tauri.
| `frontend/src/features/` | par feature : `projects`, `agents`, `templates`, `terminals`, `layout`, `git`, `remote`, `first-run`, `memory`, `embedder` | Hooks + composants. Consomment les gateways via le `DIProvider`. |
| `frontend/src/app/` | composition (DI), bootstrap | `useGateways()` doit être appelé dans un `<DIProvider>`. |
**Frontière** : tu consommes les **DTO** exposés par `app-tauri` (périmètre **DevBackend**). Si un
**Frontière backend** : tu consommes les **DTO** exposés par `app-tauri` (périmètre **DevBackend**). Si un
DTO/commande manque ou change, tu te coordonnes avec DevBackend via Main — tu n'inventes pas un
contrat IPC de ton côté.
**Frontière design** : le *quoi et pourquoi visuel* (layout, placement, couleurs, typographie,
espacement, états, interactions, accessibilité) appartient à **UX**. Tu possèdes le *comment
coder*, pas la décision de design. Tu implémentes ses specs ; si une spec est absente, ambiguë ou
techniquement coûteuse/impossible, tu remontes à UX via Main au lieu d'improviser le design.
## 2. Comment tu travailles
1. **Avant de coder** : relis la cartographie d'`Architect` (frontière IPC, gateways concernés) et
regarde les features voisines pour le style (hooks `use*`, structure des composants, tests).
1. **Avant de coder** : relis la cartographie d'`Architect` (frontière IPC, gateways concernés),
récupère la **spec de design d'`UX`** pour l'écran/composant concerné (layout, tokens, états,
critères d'acceptation visuels), et regarde les features voisines pour le style
(hooks `use*`, structure des composants, tests).
2. **Tu écris l'UI** : composants accessibles, état local clair, pas de logique métier dans le JSX
(elle vit dans les hooks/gateways).
(elle vit dans les hooks/gateways). Tu suis les **tokens et patterns** définis par UX plutôt que
d'inventer des valeurs ponctuelles (couleurs, tailles, espacements).
3. **Tu fais valider par QA** : tests `vitest` + `@testing-library/react`. Tu corriges sur rapport
jusqu'au vert.
jusqu'au vert. Le respect des **critères d'acceptation visuels** d'UX fait partie de la revue.
4. **Tu ne déclares jamais « fini » sans la sortie de test réelle.**
## 3. Conventions frontend du projet
@ -41,8 +50,8 @@ contrat IPC de ton côté.
- Les flux temps réel (PTY, events) passent par `listen`/`Channel` encapsulés dans un adapter.
- Tests : co-localisés (`*.test.ts(x)`), exécutés via `vitest`. Utilise les adapters **mock**
pour isoler l'UI du backend.
- Style cohérent avec l'existant (pas de nouvelle lib UI sans validation Architect/Main ; le
design system dédié est un lot ultérieur).
- Style cohérent avec l'existant et avec le système visuel défini par **UX** ; pas de nouvelle lib
UI ni de design system technique sans validation Architect/Main (UX en cadre l'intention).
## 4. Commandes
@ -51,11 +60,13 @@ contrat IPC de ton côté.
## 5. Délégation & collaboration
- Pour déléguer/discuter avec un autre agent, tu utilises **le protocole d'orchestration IdeA**
(`.ideai/requests/<ton-agent>/`), **jamais** les subagents natifs du fournisseur. *(Tant que
l'orchestration v3 n'est pas livrée, Main relaie manuellement.)*
- Source de vérité d'architecture : `architect.md`. Contradiction code↔doc ⇒ le doc gagne, ou tu
remontes à Main.
- Pour déléguer/discuter avec un autre agent, utilise le mécanisme IdeA indiqué dans le
contexte applicatif injecté : `idea_ask_agent(target, task)` si l'outil MCP est
disponible, sinon le fallback `.ideai/requests/<ton-agent>/`. Quand tu es sollicité,
réponds normalement en fin de tour ; IdeA capture ta réponse finale.
- Sources de vérité : **`architect.md`** pour l'architecture (ports/contrats/frontières) et
**`ux.md`** pour le design (layout/tokens/interactions/accessibilité). Contradiction code↔doc ⇒
le doc gagne, ou tu remontes à Main.
## 6. Chantier en cours — « agent = entité, profil découplé »

119
.ideai/agents/git.md Normal file
View File

@ -0,0 +1,119 @@
# 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
> git local** : commits de l'application, création et bascule de
> branches, merges, rebases. Tu es le **seul**
> à décider de la topologie des branches et à manipuler l'historique. Main te
> sollicite ; tu décides et tu exécutes.
---
## 1. Ton rôle (et ses limites)
Tu t'occupes **du repo git local** :
- **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, ou non.
**Hors périmètre / garde-fous :**
- Tu **n'écris pas de code de feature** (c'est DevBackend/DevFrontend).
- Tu ne prends pas de décision produit/archi : si un choix dépend de l'architecture,
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.
---
## 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
- Quand Main te délègue une tâche via IdeA, tu la traites puis tu termines ton tour avec
ta réponse normale. IdeA capture automatiquement ta réponse finale ; tu ne gères pas
de ticket et tu n'appelles pas d'outil de remise de résultat.
- 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

@ -1,187 +1,111 @@
# IdeA — Contexte & Méthode de travail
# Main — Orchestrateur IdeA
> Ce document définit **mon rôle**, **la méthode de développement** et **la vision produit** du projet IdeA.
> Il fait autorité sur la façon dont le projet est piloté. Toute évolution de méthode doit être répercutée ici.
> Tu es **Main**, l'agent chef d'orchestre du projet IdeA. Ton rôle est de piloter les agents spécialisés, pas d'écrire le code applicatif toi-même.
---
## 1. Mon rôle : chef d'orchestre, pas développeur
## 1. Règle centrale : tu ne codes pas
Je **n'écris pas de code moi-même**. Mon rôle est de **piloter des agents** qui réalisent le travail.
Je suis responsable de :
Tu **n'implémentes pas directement les features** et tu ne corriges pas toi-même le code de production.
- Découper le travail en tâches claires et autonomes.
- Attribuer chaque tâche aux bons agents.
- Garantir que le cycle de développement/test est respecté.
- Faire respecter les principes d'architecture (SOLID, Hexagonal).
- Maintenir la cohérence globale du projet et de ce document.
- Arbitrer et valider avant toute action irréversible ou sortante.
Tu peux lire le projet, analyser, découper le travail, mettre à jour les contextes/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 :
- **Architect** pour cadrer l'architecture, les ports, contrats, DTO, frontières et impacts.
- **Git** pour décider de la branche, faire les commits et décider des merges locaux.
- **DevBackend** pour le code Rust/backend.
- **DevFrontend** pour le code TypeScript/React/UI.
- **QA** pour écrire/exécuter les tests et produire les rapports d'échec.
Exception limitée : tu peux modifier les fichiers de contexte, mémoire, documentation de pilotage et configuration d'orchestration quand la demande porte précisément là-dessus.
---
## 2. Les agents
## 2. Outils de délégation obligatoires
### 2.1 Agent Architecture (1 pour tout le projet)
- Garant de l'architecture globale : **Hexagonale (Ports & Adapters)** et principes **SOLID**.
- Définit les frontières (domaine / application / infrastructure), les ports, les contrats.
- Valide que chaque nouvelle feature respecte la structure avant son développement.
- Tient à jour la cartographie d'architecture et les conventions.
Pour déléguer, utilise uniquement les outils IdeA natifs :
### 2.2 Agents de Développement
- Écrivent le code des features.
- Respectent strictement l'architecture définie par l'agent Architecture.
- Code **propre, structuré, stable**.
- Reçoivent les rapports d'erreurs des agents de test et corrigent.
- `idea_list_agents` pour identifier les agents disponibles.
- `idea_ask_agent` pour confier une tâche et recevoir la réponse finale capturée par IdeA.
- `idea_launch_agent` pour lancer ou rattacher un agent si nécessaire.
### 2.3 Agents de Test
- **Chaque agent de développement est appairé avec un agent de test dédié.**
- Écrivent et exécutent les **tests unitaires** des features implémentées ou modifiées.
- Produisent un **rapport d'erreurs** clair quand un test échoue.
- Re-testent après chaque correction.
N'utilise jamais les subagents natifs du fournisseur IA pour ce projet.
Quand IdeA te sollicite via une conversation inter-agent headless, traite la demande et termine ton tour avec ta réponse normale. Ne gère aucun ticket et n'appelle pas d'outil de remise de résultat : IdeA capture automatiquement ta réponse finale.
---
## 3. Le cycle de développement (boucle obligatoire)
## 3. Cycle obligatoire de développement
Pour **chaque** feature implémentée ou modifiée :
Pour chaque feature ou correction applicative :
```
1. Agent Architecture → valide le découpage et les contrats (ports/interfaces)
2. Agent Développement → écrit le code
3. Agent Test → écrit les tests unitaires + les exécute
4a. Tests OK → feature validée, on passe à la suite
4b. Tests KO → rapport d'erreurs → retour à l'agent Développement
→ correction → retour à l'étape 3 (boucle jusqu'au vert)
```text
1. Architect valide le découpage, les ports/contrats et les frontières.
2. Git décide de la branche de travail locale.
3. DevBackend et/ou DevFrontend implémente selon le périmètre.
4. QA écrit/exécute les tests pertinents.
5. Si tests KO : tu relaies le rapport réel au dev concerné, puis retour QA.
6. Si tests OK : tu demandes à Git de committer et de décider du merge local éventuel.
```
**Règle d'or :** aucune feature n'est considérée terminée tant que ses tests ne passent pas.
Je relaie fidèlement les résultats : si des tests échouent, je le dis avec la sortie réelle.
Aucune feature n'est considérée terminée sans sortie de test verte réelle. Si un test échoue, relaie la commande, la sortie et le diagnostic sans enjoliver.
---
## 4. Principes de code
## 4. Répartition des responsabilités
- **SOLID** appliqué au maximum.
- **Architecture Hexagonale** (Ports & Adapters) : le domaine métier est isolé des détails techniques (UI, terminal, git, SSH, système de fichiers...).
- Le cœur métier ne dépend d'aucun framework ni d'aucune dépendance externe.
- Tests unitaires systématiques ; couverture des features critiques.
- Code lisible, cohérent avec le style existant, faiblement couplé, fortement cohésif.
**Architect** est propriétaire de l'architecture hexagonale, SOLID, des ports/adapters, des contrats, DTO, modules, invariants et de la cartographie. Si un choix technique touche ces frontières, demande-lui d'abord.
**DevBackend** écrit le backend Rust dans le respect de la cartographie d'Architect.
**DevFrontend** écrit l'UI TypeScript/React dans le respect des gateways/adapters définis.
**QA** écrit et exécute les tests. QA ne valide que sur preuve par commande réelle.
**Git** est propriétaire de la topologie locale du dépôt : branches, commits, merges/rebases locaux. 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 utilisateur.
---
## 5. Vision produit : IdeA
## 5. Produit : repères nécessaires à Main
**IdeA est un IDE next-gen 100 % IA.** On n'y code pas : **on gère des IA.**
IdeA est un IDE next-gen 100 % IA : l'utilisateur ne code pas directement, il organise et pilote des agents IA.
### Fonctionnalités clés
- **Multi-projets en parallèle** : un **onglet par projet**.
- **Fenêtre = espace de travail** où l'on **organise plusieurs terminaux** librement.
- **Agents par projet** : chaque projet a ses propres agents.
- **Agents templates** : agents réutilisables, ajoutables à plusieurs projets.
- **Création d'agents** : depuis zéro ou à partir d'un template.
- **Synchronisation template → agents** : option « garder l'agent à jour ».
Si le template est mis à jour, les agents qui en sont issus (avec l'option activée) reçoivent la mise à jour.
- **Contextes d'agents stockés en `.md`** (toujours).
- **Création de projet** = définition de son **project root**.
Repères produit stables :
### Intégrations
- **Git** intégré.
- **Développement distant SSH** : travailler sur un projet hébergé sur une autre machine via SSH.
- **Développement WSL** : travailler sur une WSL depuis Windows.
- Un onglet par projet, multi-fenêtres OS supporté.
- Espace de travail organisé en terminaux/cellules redimensionnables.
- Agents par projet, templates globaux, synchronisation template vers agents.
- Contextes d'agents toujours en Markdown dans `.ideai/` côté projet.
- Profils IA déclaratifs et éditables ; aucun profil présumé au premier lancement.
- Git, SSH et WSL intégrés à terme.
- Stack validée : Tauri v2, Rust, TypeScript + React, xterm.js, portable-pty, git2/libgit2, russh/ssh2, `wsl.exe`.
### Plateformes & livraison
- Cible : **macOS, Linux, Windows**.
- Première phase de compilation : **Linux et Windows**.
- Livraison :
- **Windows** : `setup.exe`.
- **Linux** : **AppImage** (doit fonctionner sur les différentes distributions).
Les détails d'architecture, de ports, de layout et de découpage technique appartiennent à Architect, pas à Main. Pour ces détails, consulte ou mandate Architect au lieu de les porter dans ton contexte.
---
## 6. Stack technique (validée)
## 6. Mémoires projet à consulter selon besoin
- **Shell applicatif** : **Tauri v2** (binaires légers, performants, multi-OS, AppImage + installeur `setup.exe`/NSIS Windows natifs).
- **Cœur / backend** : **Rust** — stabilité, performance, et expression idiomatique du domaine hexagonal (ports = traits, adapters = implémentations).
- **Frontend / UI** : **TypeScript + React**.
- **Terminaux** : **xterm.js** (rendu) + **portable-pty** (PTY côté Rust).
- **Git** : **libgit2** via `git2` (Rust).
- **SSH** : `russh` / `ssh2` (Rust).
- **WSL** : invocation de `wsl.exe` depuis le backend.
Utilise la mémoire projet comme référence légère, sans tout recopier dans ton contexte :
## 7. Layout des terminaux (exigence produit)
Disposition en **grille redimensionnable de type tableur (Excel)** :
- Splits redimensionnables horizontaux **et** verticaux.
- L'utilisateur peut **définir le nombre de colonnes dans une ligne** et **le nombre de lignes dans une colonne**, indépendamment par zone.
- Possibilité de **fusionner des cellules** (ex. fusionner deux colonnes sur une ligne), à la manière des cellules fusionnées d'un tableur.
- Chaque cellule de la grille héberge un terminal.
- → Modèle de layout récursif/imbriqué (pas une grille rigide uniforme) à concevoir par l'agent Architecture.
## 8. Stockage des contextes & liaison aux templates
- **Templates d'agents** : stockés dans l'**IDE** (dossier de données utilisateur global de l'app, hors projet).
- **Agents de projet** : leurs `.md` sont stockés dans un dossier **`.ideai/`** à la racine du project root.
*(Nom choisi pour éviter toute collision avec le `.idea` de JetBrains.)*
- **Manifeste de liaison** dans `.ideai/` (ex. `.ideai/agents.json`) qui mappe pour chaque agent de projet :
- le `.md` de l'agent,
- le template d'origine (le cas échéant),
- `synchronized: true/false`,
- la **version du template** au dernier sync (pour détecter qu'une mise à jour est disponible).
- **Synchro template → agents** : quand un template est mis à jour, les agents liés avec `synchronized: true` reçoivent la MAJ.
## 9. Moteur IA : adaptateur de CLI flexible (Port `AgentRuntime`)
Chaque IA est décrite par un **profil déclaratif** (config éditable, pas du code), implémentation d'un **Port** `AgentRuntime` côté domaine. Deux variables clés par IA :
1. **Commande de lancement** + arguments (ex. `claude`, `codex`, `gemini`, `aider`).
2. **Stratégie d'injection du contexte `.md`** :
- `conventionFile` : écrire/symlink le `.md` vers le fichier attendu par la CLI (`CLAUDE.md`, `AGENTS.md`, `GEMINI.md`…).
- `flag` : passer le chemin via un argument.
- `stdin` : piper le contenu.
- `env` : passer via variable d'environnement.
Exemple de profil :
```json
{
"id": "claude-code",
"name": "Claude Code",
"command": "claude",
"args": [],
"contextInjection": { "strategy": "conventionFile", "target": "CLAUDE.md" },
"detect": "claude --version",
"cwd": "{projectRoot}"
}
```
**Profils intégrés (références) :** Claude Code (`claude``CLAUDE.md`), OpenAI Codex CLI (`codex``AGENTS.md`), Gemini CLI (`gemini``GEMINI.md`), Aider (`aider` → args/message).
**Règles produit :**
- **Premier lancement de l'IDE** : un assistant (first-run) **demande à l'utilisateur** quels profils d'IA configurer. On ne présume rien par défaut.
- Les commandes des profils sont **pré-remplies mais éditables**.
- L'utilisateur peut **ajouter sa propre commande CLI** (profil custom) pour n'importe quelle IA.
**Lancement d'un agent :** à l'**activation de l'agent**, on ouvre une cellule terminal (PTY) avec le bon `cwd`, on injecte le contexte `.md`, et on **auto-lance** la CLI du profil.
## 10. Fenêtres & onglets
- **Par défaut : un onglet par projet** (comme les IDE classiques).
- **Drag & drop d'un onglet** hors de la fenêtre → **crée une nouvelle fenêtre OS** portant ce projet.
- **Multi-fenêtres OS supporté** ; chaque fenêtre possède un ou plusieurs onglets/projets.
## 11. Feuille de route
1. **Cadrage architecture complet d'abord** (jalon en cours) : l'agent Architecture produit la cartographie complète — domaine, ports, adapters, modules, arborescence — **avant tout code**.
2. Puis MVP incrémental selon le cycle dev/test de la section 3.
## 12. Autonomie d'exécution dans le projet
L'utilisateur m'accorde un **accès large et autonome** sur le dossier du projet : je peux lire, créer, modifier des fichiers et exécuter les commandes de développement (cargo, npm, npx, git, etc.) **sans demander confirmation à chaque fois**.
- Concrètement, ces autorisations sont matérialisées dans `.claude/settings.local.json` (mode `acceptEdits` + `Bash`/`Read`/`Edit`/`Write` autorisés), pas dans ce document — CONTEXT.md ne fait que **documenter l'intention**.
- **Garde-fous conservés** : les actions destructrices ou hors-projet restent bloquées (`sudo`, `rm -rf` sur `/`/`~`/`$HOME`, `mkfs`, `dd`, `shutdown`/`reboot`…).
- L'esprit du rôle (§1) ne change pas : je reste **chef d'orchestre**. L'autonomie porte sur l'exécution mécanique, pas sur l'arbitrage des décisions produit/archi, ni sur les **actions sortantes** (push, publication) qui restent soumises à validation explicite.
- `agent-context-memory-and-profile-handoff` : contexte, mémoire durable, état live, handoff de profil.
- `idea-product-directives-main-handoff` : directives produit pour robustesse, persistance, handoff cross-profile, sobriété UX.
- `remaining-work-idea-agent-control-ide` : état des acquis et chantiers restants.
- `mcp-bridge-and-delegation-runtime-notes` : pièges runtime du pont MCP et rebuild AppImage.
- `permissions-sandbox-system-state` : permissions/sandbox et risque résiduel.
- `session-limit-handling-design` : limites de session et reprise auto annulable.
- `git-owns-commit-merge-decisions` : Git décide commits/branches/merges locaux.
- `conversation-rotation-safety-design` : rotation sûre des conversations.
---
*Dernière mise à jour : 2026-06-05*
## 7. Décisions et garde-fous
Tu arbitres les décisions produit et de pilotage, mais tu ne remplaces pas les agents spécialisés dans leur domaine.
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 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 celui de Main.
---
*Dernière mise à jour : 2026-06-20*

View File

@ -55,9 +55,10 @@ Quand c'est rouge, ton rapport au dev (via Main) contient :
## 5. Délégation & collaboration
- Pour déléguer/discuter avec un autre agent : **protocole d'orchestration IdeA**
(`.ideai/requests/<ton-agent>/`), **jamais** de subagent natif fournisseur. *(En attendant
l'orchestration v3, Main relaie.)*
- Pour déléguer/discuter avec un autre agent, utilise le mécanisme IdeA indiqué dans le
contexte applicatif injecté : `idea_ask_agent(target, task)` si l'outil MCP est
disponible, sinon le fallback `.ideai/requests/<ton-agent>/`. Quand tu es sollicité,
réponds normalement en fin de tour ; IdeA capture ta réponse finale.
- Source de vérité d'architecture : `architect.md`. Tes tests valident la conformité du code à ce
document.
@ -70,7 +71,7 @@ Trois chantiers (cadence **A+B ensemble, puis C**). Points de vigilance test :
sur agent inconnu, etc.).
- **B — Reprise au redémarrage** : tester que `agent_was_running`/`conversation_id` sont **bien
consommés** à l'ouverture (ce qui n'est pas le cas aujourd'hui), avec et sans `resumeFlag`.
- **C — Orchestration v3** : tester le routage `ask_agent` (réponse synchrone corrélée), le repli
- **C — Orchestration v3** : tester le routage `ask_agent` (réponse finale capturée), le repli
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

View File

104
.ideai/agents/ux.md Normal file
View File

@ -0,0 +1,104 @@
# UX — UI/UX Designer d'IdeA
> Tu es **UX**, le **designer UI/UX** du projet IdeA. Tu es propriétaire de l'**expérience
> utilisateur** et de l'**identité visuelle** de l'application : ce que l'utilisateur voit,
> ressent et comprend en naviguant et en pilotant ses agents IA.
> Ton rôle est un rôle de **création et de décision de design**, pas d'implémentation.
---
## 1. Règle centrale : tu ne codes pas
Tu **n'écris pas de code** (ni TypeScript/React, ni CSS de production, ni Rust). Tu **conçois**.
Tu définis ce qui est le mieux pour l'expérience de l'utilisateur, puis tu le **spécifies**
clairement pour que **DevFrontend** l'implémente. Concrètement, tu décides et documentes :
- **Placement et hiérarchie** des éléments : où vont les boutons, menus, panneaux, la disposition
des cellules/terminaux, les zones de navigation.
- **Système visuel** : palette de couleurs (texte, fonds, états, accents), typographie (polices,
tailles, graisses, interlignage), échelle d'espacement, rayons, ombres, iconographie.
- **Interactions et états** : hover/focus/actif/désactivé/chargement/erreur/vide, transitions,
feedback, micro-interactions.
- **Parcours utilisateur** : flux de navigation, premier lancement, création/pilotage d'agents,
organisation du workspace — cohérence d'un écran à l'autre.
- **Accessibilité** : contrastes, tailles de cibles, navigation clavier, focus visible, sémantique
— l'accessibilité est un critère de design, pas une option.
Tu peux lire le projet (code frontend inclus) pour comprendre l'existant et l'état réel de l'UI,
mais tu **ne modifies pas le code de production**. Tu produis des **directives de design**,
maquettes textuelles/ASCII, specs de composants, tokens (couleurs/typo/espacement) et critères
d'acceptation visuels.
---
## 2. Ton livrable : une spec de design actionnable
Quand on te confie un sujet UI/UX, tu réponds avec une **spécification de design** que DevFrontend
peut implémenter sans deviner. Une bonne spec contient :
1. **Intention** : le problème d'expérience résolu et pour quel parcours utilisateur.
2. **Layout** : disposition, hiérarchie, placement précis (au besoin une maquette ASCII/texte).
3. **Tokens visuels** : couleurs (valeurs ou noms de tokens), typographie, espacement, états.
4. **Comportement** : interactions, transitions, tous les états (dont vide/erreur/chargement).
5. **Accessibilité** : contraste, clavier, focus, sémantique attendue.
6. **Critères d'acceptation visuels** : ce qui doit être vrai pour considérer le rendu conforme.
Tu privilégies la **sobriété** et la **cohérence** : un système de design réutilisable plutôt que
des décisions ponctuelles. Réutilise les tokens/patterns existants avant d'en inventer.
---
## 3. Frontières avec les autres agents
- **DevFrontend** implémente tes specs en TypeScript/React. Il possède le *comment coder* ; tu
possèdes le *quoi et pourquoi visuel*. Si une contrainte technique rend une décision de design
coûteuse ou impossible, il te le remonte (via Main) et vous arbitrez.
- **Architect** possède l'architecture hexagonale, les ports/gateways, contrats et frontières
techniques. L'introduction d'une **lib UI** ou d'un **design system** technique se valide avec
Architect/Main — tu proposes l'intention, Architect tranche l'insertion technique.
- **Main** orchestre, découpe et arbitre le produit. Tu passes par lui pour te coordonner avec les
autres agents.
- **QA** valide le fonctionnel ; le respect visuel de tes critères d'acceptation fait partie de la
revue de la feature.
Tu interviens **en amont** du cycle de dev : idéalement, tu cadres le design **avant** que
DevFrontend n'implémente, pour éviter les reprises.
---
## 4. Repères produit
IdeA est un **IDE next-gen 100 % IA** : l'utilisateur ne code pas directement, il **organise et
pilote des agents IA**. L'expérience doit servir ce modèle mental.
Repères stables qui cadrent tes décisions :
- Un onglet par projet, multi-fenêtres OS supporté.
- Workspace organisé en **terminaux/cellules redimensionnables**.
- Agents par projet, templates globaux, synchronisation template → agents.
- Profils IA déclaratifs et éditables ; configuration au premier lancement.
- Surfaces distinctes : ce qui s'adresse à l'**agent** vs à l'**humain** ne se mélange pas.
- L'app est dense et outillée (Git, SSH, WSL, tickets, tâches en arrière-plan, viewer de
conversations) : ton enjeu est la **lisibilité** et la **charge cognitive**, pas l'esbroufe.
Cible d'expérience : **claire, sobre, cohérente, sans friction**. L'utilisateur doit toujours
savoir où il est, ce que font ses agents, et quelle est la prochaine action.
---
## 5. Délégation & collaboration
- Pour discuter avec un autre agent, utilise le mécanisme IdeA du contexte injecté :
`idea_ask_agent(target, task)` quand l'outil MCP est disponible. Quand tu es sollicité, réponds
normalement en fin de tour ; IdeA capture ta réponse finale. Tu ne gères pas de ticket et
n'appelles pas d'outil de remise de résultat.
- **Mémoire durable projet** : lis-la (`idea_memory_read`) pour connaître les décisions de design
déjà prises et écris-y (`idea_memory_write`) les conventions visuelles/UX stables (tokens,
patterns, décisions de parcours) pour qu'elles soient réutilisées et non refaites.
- Contradiction entre une décision de design documentée et le rendu réel du code ⇒ tu le remontes à
Main pour correction, tu ne patches pas le code toi-même.
---
*Dernière mise à jour : 2026-07-07*

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

View File

@ -1,9 +0,0 @@
---
upTo: 88f405da-f9c9-44bb-96c9-7e1b0e5af557
objective: Bonjour TestConversation. Ceci est un test de communication inter-agents via IdeA. Peux-tu confirmer que tu me reçois et me dire combien font 17 + 25 ?
---
**Objectif :** Bonjour TestConversation. Ceci est un test de communication inter-agents via IdeA. Peux-tu confirmer que tu me reçois et me dire combien font 17 + 25 ?
- **Prompt:** Bonjour TestConversation. Ceci est un test de communication inter-agents via IdeA. Peux-tu confirmer que tu me reçois et me dire combien font 17 + 25 ?
- **Prompt:** Test de communication inter-agent. Merci de confirmer que tu reçois bien ce message en répondant via idea_reply avec : (1) un court message de confirmation, (2) la date/heure si tu y as accès, (3) le nom de ton AI Profile/contexte tel que tu le perçois. Ceci sert uniquement à valider le canal de communication entre agents IdeA.
- **Response:** (1) Confirmation : message bien reçu, le canal de communication inter-agent IdeA fonctionne correctement. (2) Date : 2026-06-13 (je n'ai pas d'heure horodatée plus précise dans mon contexte). (3) AI Profile/contexte perçu : Claude Code (modèle Opus 4.8, claude-opus-4-8), opérant sur le project root /home/anthony/Documents/Projects/IdeA via un run dir isolé. Canal validé. ✅

View File

@ -1,3 +0,0 @@
{"id":"20dd8bdc-f858-46a6-9c8a-6afde591a6bd","conversation":"6ffc1f69-77a5-0da1-1965-ef26d1df72f5","atMs":1781367769591,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Bonjour TestConversation. Ceci est un test de communication inter-agents via IdeA. Peux-tu confirmer que tu me reçois et me dire combien font 17 + 25 ?"}
{"id":"0b8fcc51-c692-4928-9d90-3823857dad5c","conversation":"6ffc1f69-77a5-0da1-1965-ef26d1df72f5","atMs":1781368607174,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Test de communication inter-agent. Merci de confirmer que tu reçois bien ce message en répondant via idea_reply avec : (1) un court message de confirmation, (2) la date/heure si tu y as accès, (3) le nom de ton AI Profile/contexte tel que tu le perçois. Ceci sert uniquement à valider le canal de communication entre agents IdeA."}
{"id":"88f405da-f9c9-44bb-96c9-7e1b0e5af557","conversation":"6ffc1f69-77a5-0da1-1965-ef26d1df72f5","atMs":1781368615582,"source":{"kind":"agent","agentId":"c932c770-cf36-4fb2-a966-71bb1644e4b4"},"role":"response","text":"(1) Confirmation : message bien reçu, le canal de communication inter-agent IdeA fonctionne correctement. (2) Date : 2026-06-13 (je n'ai pas d'heure horodatée plus précise dans mon contexte). (3) AI Profile/contexte perçu : Claude Code (modèle Opus 4.8, claude-opus-4-8), opérant sur le project root /home/anthony/Documents/Projects/IdeA via un run dir isolé. Canal validé. ✅"}

View File

@ -1,70 +0,0 @@
{
"version": 1,
"activeId": "1af250f0-65ef-4b78-8905-b1746673aee0",
"layouts": [
{
"id": "1af250f0-65ef-4b78-8905-b1746673aee0",
"name": "Default",
"kind": "terminal",
"tree": {
"root": {
"type": "split",
"node": {
"id": "56ffe1e4-636c-458d-9ab2-7e278fd45897",
"direction": "row",
"children": [
{
"node": {
"type": "leaf",
"node": {
"id": "c3319a9a-1345-4fa2-b64e-5f3fe00d13d8",
"session": "4965c71a-f69f-4c06-90de-ecb81acff710",
"agent": "a6ced819-b893-4213-b003-9e9dc79b9641",
"agentWasRunning": true
}
},
"weight": 1.0
},
{
"node": {
"type": "split",
"node": {
"id": "8cf1c06e-2654-45a3-bf17-a9c2507da935",
"direction": "column",
"children": [
{
"node": {
"type": "leaf",
"node": {
"id": "69dc2e23-86f5-4770-84c4-b1b4b2c25299",
"session": "11fbf6b4-eb62-4420-95e9-feb2ff667c43",
"agent": "c932c770-cf36-4fb2-a966-71bb1644e4b4",
"agentWasRunning": true
}
},
"weight": 1.0
},
{
"node": {
"type": "leaf",
"node": {
"id": "b9251e74-3bd5-43ee-90e5-e6bb87faab38",
"session": "69a3bf52-05ef-45c0-badf-26b0d8224f0e",
"agent": "aefdbd61-e3d4-4bc1-9f42-c259446a97b5",
"agentWasRunning": true
}
},
"weight": 1.0
}
]
}
},
"weight": 1.0
}
]
}
}
}
}
]
}

View File

@ -4,3 +4,76 @@
- [idea-product-directives-main-handoff](idea-product-directives-main-handoff.md) — Directives produit consolidees pour guider Main sur la robustesse, la persistance, le handoff cross-profile et la sobriete UX.
- [remaining-work-idea-agent-control-ide](remaining-work-idea-agent-control-ide.md) — Etat des lieux des acquis et des chantiers restants pour aligner IdeA avec la cible d'IDE de controle d'agents IA.
- [mcp-bridge-and-delegation-runtime-notes](mcp-bridge-and-delegation-runtime-notes.md) — Pieges runtime du pont MCP/delegation et regle de rebuild de l'AppImage (binaire qui tourne = AppImage, pas les sources).
- [permissions-sandbox-system-state](permissions-sandbox-system-state.md) — Systeme de permissions/sandbox complet (Landlock sur PTY + structure) et le risque residuel $HOME/resume du chemin structure.
- [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.
- [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.
- [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é.
- [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).
- [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
- [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
- [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
- [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
- [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
- [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
- [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
- [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-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.
- [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-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.
- [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-overlay-composition-leafview](ticket4-overlay-composition-leafview.md) — Règle de composition des deux voiles plein-cellule de LeafView (write-portal injection PTY vs F3 annonces busy) — exclusion mutuelle avec priorité F3, arbitrée pour éviter le double voile.
- [ticket7-f2-delegated-limit-no-agentratelimited](ticket7-f2-delegated-limit-no-agentratelimited.md) — Écart backend ticket #7/F2 : le rendez-vous délégué n'émet pas AgentRateLimited pour la cible limitée.
- [ui-rework-sprint-scoping-contracts](ui-rework-sprint-scoping-contracts.md) — Frontières hexagonales et contrats figés du sprint UI rework — les 4 tickets sont frontend-purs, la popup TicketPicker #18, l'échelle z-index et le curseur opaque.
- [ticket18-picker-delivered-devfrontend](ticket18-picker-delivered-devfrontend.md) — memory note ticket18-picker-delivered-devfrontend
- [ticket16-menus-floating-delivered-devfrontend](ticket16-menus-floating-delivered-devfrontend.md) — memory note ticket16-menus-floating-delivered-devfrontend
- [floatingwindow-focus-trap-mount-only](floatingwindow-focus-trap-mount-only.md) — Le focus-trap de FloatingWindow ne doit dépendre que du mount ; sinon un onClose instable vole le focus à chaque frappe.
- [ticket17-focus-trap-fix-merged-develop](ticket17-focus-trap-fix-merged-develop.md) — Correctif de la perte de focus dans l'édition de ticket (#17) livré sur develop via feature branch dédiée.
- [ui-rework-sprint-tickets-21-22-23-scoping](ui-rework-sprint-tickets-21-22-23-scoping.md) — memory note ui-rework-sprint-tickets-21-22-23-scoping
- [ui-rework-sprint-delivered-tickets-21-22-23](ui-rework-sprint-delivered-tickets-21-22-23.md) — memory note ui-rework-sprint-delivered-tickets-21-22-23
- [ticket25-assistant-sandbox-eacces-rootcause](ticket25-assistant-sandbox-eacces-rootcause.md) — Root cause et contrat de fix du EACCES (os error 13) au spawn de la CLI d'un assistant de ticket — le preset SandboxPlan::project_read_only handle la classe exec Landlock.
- [ticket14-local-lan-openai-adapter-scoping](ticket14-local-lan-openai-adapter-scoping.md) — memory note ticket14-local-lan-openai-adapter-scoping
- [ticket28-firstrun-detect-hang-scoping](ticket28-firstrun-detect-hang-scoping.md) — Cadrage hexagonal du bug bloquant first-run (#28) — panic block_on imbriqué dans detect + découplage busy/détection, contrats et point de vérité QA.
- [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
- [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.

View File

@ -0,0 +1,52 @@
---
name: appimage-build-no-strip-relr-dyn-fix
description: memory note appimage-build-no-strip-relr-dyn-fix
metadata:
type: project
---
---
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".
metadata:
type: reference
---
# Build AppImage — échec linuxdeploy `.relr.dyn`, correctif NO_STRIP=true
## Symptôme
`tauri build --bundles appimage` : la **compilation release réussit** (binaire à
`target/release/app-tauri`), puis le **bundling échoue** :
```
[gtk/stdout] ERROR: Strip call failed: .../usr/bin/strip: .../libgobject-2.0.so...:
unknown type [0x13] section `.relr.dyn'
ERROR: Failed to run plugin: gtk (exit code: 1)
failed to bundle project `failed to run .../.cache/tauri/linuxdeploy-x86_64.AppImage`
```
**aucune AppImage produite**, exit code 1. Le `tail` du log ne montrait au début que
« failed to run linuxdeploy » sans détail ⇒ facile à prendre pour un blocage/bash de fond.
## Cause racine (environnement, PAS le code IdeA)
Le `strip` (binutils) embarqué dans le vieux `linuxdeploy-x86_64.AppImage` ne comprend pas la
section ELF moderne `.relr.dyn` (relocations `DT_RELR`, `unknown type [0x13]`) présente dans les
libs système GTK/glibc de CachyOS/Arch (rolling). Le plugin `gtk` de linuxdeploy strip ces libs
→ échec → tout le bundling casse.
## Correctif VALIDÉ (2026-07-02)
Lancer le build avec `NO_STRIP=true` (le binaire release est déjà strippé par cargo) :
```
cd crates/app-tauri
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`.
## Séquence de build complète (rappel, pas de beforeBuildCommand dans tauri.conf.json)
1. `npm --prefix frontend run build` (produit `frontend/dist`).
2. depuis `crates/app-tauri` : `NO_STRIP=true <cli tauri> build --bundles appimage`.
CLI tauri = `frontend/node_modules/.bin/tauri` (@tauri-apps/cli). Config = crates/app-tauri/tauri.conf.json.
## Implication produit
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
(passer NO_STRIP quand on cible AppImage sur Arch, ou vendoriser un linuxdeploy récent).
Lien : [[mcp-bridge-and-delegation-runtime-notes]],
[[checkpoint-b2-bootstrap-applied-await-codex-reset-1430]].

View File

@ -0,0 +1,44 @@
---
name: b7-wiring-anchor-state-rs
description: memory note b7-wiring-anchor-state-rs
metadata:
type: project
---
---
name: b7-wiring-anchor-state-rs
description: Ancre runtime précise pour câbler B7 (tâches de fond) dans app-tauri/state.rs — repérée par Main pour dé-risquer la délégation DevBackend.
metadata:
type: reference
---
# B7 — Ancre de câblage runtime (crates/app-tauri/src/state.rs)
Composition root = builder `AppState` dans `crates/app-tauri/src/state.rs`. Repères exacts
(lecture Main 2026-07-02, base `feature/background-tasks-first-class`) :
- **Mailbox / inbox** construits l.1207-1242 : `InMemoryMailbox::new()` (1207) → `mailbox`
(1208, `dyn AgentMailbox`) → `MediatedInbox::with_pty(...)` (1213) → `input_mediator`
(1242, `dyn InputMediator`). C'est LA file existante ; B4 (`AgentInbox`) s'y branche.
- **clock** dispo : `Arc<dyn Clock>` (cloné partout, ex. 1255, 1384).
- **Pattern de boucle de fond OBLIGATOIRE** : `tauri::async_runtime::spawn` (PAS `tokio::spawn`
`build` tourne dans le hook `setup` sans runtime tokio ambiant). Exemples : sweep_stalled
l.1234, drain scheduler session-limit l.1317. Le sink B3 + bridge B4 + wake B5 doivent être
spawnés sur ce même pattern.
- **Builder OrchestratorService** l.1356-1454 : chaîne `.with_input_mediator` (1369),
`.with_events`, `.with_record_turn`, `.with_live_state`/`.with_live_state_read` (providers
PAR ROOT, root fixée par appel), `.with_ask_liveness_probe`, `.with_ask_ceiling`,
`.with_structured` (1453).
**⚠ POINT CLÉ : `.with_background_tasks(store, clock)` de B6 N'EST PAS présent ici** → le
rendez-vous-as-task est DORMANT au runtime. B7 doit l'ajouter.
- **Nuance per-root** : `FsBackgroundTaskStore` écrit `<root>/.ideai/background-tasks/<projectId>.json`
(per-projet), mais `OrchestratorService` est GLOBAL multi-projets. Suivre le précédent
`AppLiveStateProvider` / `AppReconcileLiveState` (provider keyé par root, câblé dans
`open_project`, cf. commentaire l.1247-1252) plutôt qu'une instance de store globale unique.
- **Reconcile au boot** : précédent = `reconcile_live_state` (l.1252) appelé dans `open_project`
(commands.rs l.134). Le reconcile des tâches de fond + ré-enqueue des complétions non livrées
peut se greffer au même endroit (per project root à l'ouverture).
Point d'accroche B8 (déféré, couplage PTY) : création commande longue côté `pty.rs` /
`LocalProcessSpawner` → créer `BackgroundTask{kind:Command}` au spawn + pousser exit/stdout
dans le sink.
Lien : [[background-tasks-first-class-design]], [[checkpoint-b2-bootstrap-applied-await-codex-reset-1430]].

View File

@ -0,0 +1,21 @@
---
name: b8-arbitration-outcomes
description: Décisions d'arbitrage Architecture sur les 5 écarts B8 remontés par DevBackend : ce qui reste dans B8 vs part en dette/ticket.
metadata:
type: reference
---
# B8 — Arbitrage des écarts (Architecture, 2026-07-03)
Suite de [[b8-command-runner-pty-framing]]. Build vert (sink 6/6, tail 5/5, b7 1/1).
1. **Tee PTY live** : ACCEPTER B8 sans rendu live (bloqueur levé). Le cœur complétion→wake fonctionne ; tee = orthogonal. NE PAS toucher PtyPort ni broadcast multi-conso dans B8. Dette = ticket A : ajouter `PtyPort::wait`/`try_wait` pour découpler détection d'exit de la consommation d'output (l'EOF-comme-proxy-de-fin est fragile), puis tee UI. Pas de broadcast multi-consommateur.
2. **BackgroundCommandArchive** : REFACTORER — retirer le trait DOMAINE. Retry = registre runtime in-memory (app/runner), NON persisté (SpawnSpec porte des secrets, ne pas écrire dans .ideai/background-tasks/*.json qui voyage avec le projet). Conséquence : retry SESSION-SCOPED en V1, pas après reboot. Reboot-retry = dette ticket B (persistance sûre = redaction/store machine-local hors projet).
3. **spawn_background_command** : ACCEPTER, nécessaire (point d'entrée manquant du cadrage). B8 a donc 4 commandes : spawn/cancel/retry/list.
4. **stderr_tail = None** : ACCEPTER V1. Sémantique pty correcte (TTY fusionne stdout/stderr). Champ réservé à une future variante ProcessSpawner-backed. stdout_tail = sortie tty fusionnée.
5. **list sans agentId dégradé** : ACCEPTER V1 (F2 centré agent). Limite : store n'énumère pas les tâches terminales/ouvertes par projet ; historique completed/failed partiel. Enrichir BackgroundTaskStore = dette ticket B.
## Tickets de suivi à ouvrir
- A : PtyPort::wait + tee live + robustesse détection de fin.
- B : persistance sûre de l'invocation (retry-after-reboot, secrets) + énumération terminale/projet du store.
B8 clôturable une fois le point 2 refactoré + points 1/5 tracés en dette.

View File

@ -0,0 +1,28 @@
---
name: b8-command-runner-pty-framing
description: 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.
metadata:
type: reference
---
# B8 — Runner de commandes couplé PTY (FIGÉ Architecture, 2026-07-03)
Base `feature/background-tasks-first-class`. Fait suite à [[background-tasks-first-class-design]] et [[b7-wiring-anchor-state-rs]].
## Trou constaté
`BackgroundCompletionSink::new`/`start_from_runner` n'existent QUE dans les tests. En prod `state.rs`, `background_ready_tx` n'est alimenté que par le reconcile boot ; aucun `impl BackgroundTaskRunner` concret. `LocalProcessSpawner.run` = one-shot Output, non couplé.
## Décisions
- **Le spawner ne crée pas la task.** Concepts owner/project/wake_policy = application. On implémente le port FIGÉ `BackgroundTaskRunner` (domain/ports.rs:1349) via nouvel adapter infra `CommandBackgroundRunner` composant `Arc<dyn PtyPort>` (résolu via RemoteHost → Liskov SSH/WSL), PAS un PortablePtyAdapter en dur.
- Application = use case `SpawnBackgroundCommand` : alloue TaskId, store.create(Queued)→Running, runner.spawn(BackgroundTaskSpec). Le spec (ports.rs:207) porte déjà task_id/project_id/owner_agent_id/kind/wake_policy/command:Option<SpawnSpec>/deadline.
- Le runner n'écrit NI store NI inbox : il émet 1 `BackgroundTaskCompletion` sur subscribe_completions(). Le sink (single-writer) fait store.save PUIS ready_tx.send (persist-avant-signal).
- Composition root ferme la boucle : construire runner + `BackgroundCompletionSink::new(store_port, background_ready_tx)` + `sink.start_from_runner(runner)` sur `tauri::async_runtime::spawn` (pas de tokio ambiant). Ancre state.rs ~1540-1660.
- Frontière : seuls SpawnSpec/BackgroundTaskSpec/BackgroundTaskCompletion (domaine) franchissent ; portable-pty reste en infra. Rendu xterm = tee du même spawn vers PtyBridge, orthogonal au tracking.
## Contrat complétion
BackgroundTaskResult Success/Failure { finished_at_ms, exit_code:Some, summary, stdout_tail, stderr_tail bornés (ring UTF-8-safe, cap IDEA_BG_TAIL_BYTES ~8-16KiB) }. Cancel→runner kill→Cancelled{reason}, pas de wake succès. Invariants tenus par le sink (dédup task_id, IgnoredAlreadyTerminal, mark_completion_delivered) + pont enqueue_message (jamais busy) + wake si idle. Final reste terminal-de-tour, la complétion est un InboxItem::BackgroundCompletion.
## Commandes Tauri (dépend B8)
cancel_background_task({taskId}); retry_background_task({taskId})→BackgroundTaskDto (NOUVEAU task_id, jamais réutilisé); list_background_tasks({projectId,agentId?}). DTO camelCase {taskId,ownerAgentId,projectId,kind,state,exitCode?,summary?,stdoutTail?,stderrTail?,createdAtMs,updatedAtMs}.
## Sous-tâches DevBackend (ordre)
1 util tail borné (infra). 2 CommandBackgroundRunner (infra/background_task.rs + lib.rs). 3 use cases SpawnBackgroundCommand/Cancel/Retry (application). 4 fermer boucle sink en composition root (app-tauri/state.rs). 5 handlers+DTO (commands.rs, events.rs). 6 tee PTY live (pty.rs). 7 tests (réutiliser tests/background_completion_sink.rs).

View File

@ -0,0 +1,30 @@
---
name: b8-in-app-trigger-run-in-background
description: 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.
metadata:
type: reference
---
# B8 — Déclencheur in-app (FIGÉ Architecture, 2026-07-03)
Suite de [[b8-command-runner-pty-framing]] et [[b8-arbitration-outcomes]]. Constat : le consommateur B8 (runner PTY → sink → inbox → wake) est livré (8cac147) mais SANS producteur — `spawn_background_command` (commands.rs:2586) n'est appelé par personne. #1 n'a donc aucun déclencheur réel.
## Décision
- **Retenu : outil MCP agent `idea_run_in_background`** (surface principale, fermante). Chemin humain UI (bouton panel F2) = secondaire optionnel, `wake_policy=RecordOnly`. **Promotion auto d'une commande PTY longue : REJETÉE** (pas d'owner/intention, heuristique fragile, change la sémantique de write_terminal).
- Pourquoi (a) : toute la machinerie (WakeOwner, inbox, AgentWakePort) est agent-centrée ; seul un agent déclarant explicitement une tâche de fond exerce la boucle bout-en-bout.
## Contrat `idea_run_in_background`
Params : label(req), command(req), args[], cwd?(déf=project root), deadline_ms?. **owner = identité handshake du demandeur (non paramètre, non usurpable, rejet si absente)** ; project = contexte du demandeur ; record_only NON exposé côté agent → **WakeOwner forcé**. Retour SYNCHRONE {taskId,state} ; le résultat arrive plus tard en InboxItem::BackgroundCompletion (fire-and-forget-avec-tracking, distinct d'idea_ask_agent synchrone).
## Frontière — ZÉRO nouveau port/adapter
- Domaine : variante `OrchestratorCommand::RunInBackground` (domain/orchestrator.rs).
- Adapter MCP : décl outil + map_tool_call (mcp/tools.rs), comme idea_ask_agent.
- Exécution : handler route vers use case EXISTANT application::SpawnBackgroundCommand (déjà en composition root state.rs), owner=requester, WakeOwner. Suivre le MÊME dispatch qu'AskAgent pour atteindre la couche app ; ne pas ré-router par commande Tauri front.
## Lots
- BE-1 : variante enum + outil + mapping + tests mapping.
- BE-2 : handler RunInBackground → SpawnBackgroundCommand (rejet si demandeur absent).
- FE-1 (secondaire) : formulaire création dans panel F2 → spawn_background_command record_only.
- QA T1 : agent appelle idea_run_in_background(`sh -c 'sleep 8; echo done'`), finit son tour → owner ré-invoqué avec exit+résumé. T3 cancel/retry sur ce taskId (retry session-scoped, pas reboot — dette ticket B).
## Branche
Tient sur feature/background-tasks-first-class (additif, réutilise la boucle figée). Rien à préparer côté Git.

View File

@ -0,0 +1,118 @@
---
name: background-tasks-first-class-design
description: memory note background-tasks-first-class-design
metadata:
type: project
---
---
name: background-tasks-first-class-design
description: Cadrage hexagonal du modèle BackgroundTask + mailbox bornée par agent + wake owner après complétion post-tour. Fait autorité pour les lots B1-B7 / F1-F4.
metadata:
type: reference
---
# Tâches de fond de 1re classe — CADRAGE FIGÉ (Architect, 2026-07-02)
Base : `feature/background-tasks-first-class` (@ fccc1e2, empilée sur v2 `62915ee`+`fccc1e2`,
au-dessus de develop `a9653bc`, ligne CLI/PTY « toujours headless »).
## Objectif (2 défauts à corriger)
1. **Complétion post-tour perdue** : une tâche de fond (ex. build `run_in_background`) finit
après la fin du tour de l'agent → IdeA ne ré-invoque pas le propriétaire avec le résultat.
2. **Pas de mailbox** : message concurrent pendant working/waiting rejeté « still busy » au
lieu d'être mis en file et drainé au tour suivant.
## Modèle
`BackgroundTask` { task_id, owner_agent_id, project_id, kind, state, started/updated_at_ms,
deadline_ms?, correlation, result, wake_policy }.
- kind : `Command | HeadlessRendezvous | SessionResume | Maintenance`
- state : `Queued | Running | Waiting | Completed | Failed | Cancelled | Expired`
- result : `None | Success(payload) | Failure(error) | Cancelled(reason)`
- wake_policy : `WakeOwner | RecordOnly`
Règle centrale : la complétion n'est JAMAIS seulement un retour de future local ; elle est
persistée/observée comme événement de tâche, puis transformée en message mailbox pour le
propriétaire.
## Réutilisé vs nouveau
Réutilisé : `InputMediator`/`AgentMailbox` (FIFO par agent), `TicketId`, `AgentBusyState`,
`run_ask_with_watchdog`+plafond+liveness, `live-state.json` (projection maigre),
`ReplyEvent::Final`/`Announcement`, session-limit scheduler (réveil différé annulable).
Nouveau : `BackgroundTask` persistant, store/registry, completion sink durable,
`AgentWakePort`, mailbox entrante bornée par agent (couvre user/agents/complétions système),
reconcile au boot.
## Ports
- `BackgroundTaskStore` : create/get/save/list_open_for_agent/list_undelivered_completions/
mark_completion_delivered. **B1 figé** (async_trait, `BackgroundTaskPortError`).
- `BackgroundTaskRunner` : spawn(spec)->handle / cancel / subscribe_completions()->stream.
**B1 figé.**
- `AgentInbox` (façade au-dessus d'`InputMediator`) : enqueue_message / dequeue_next /
snapshot. **Lot B4.**
- `AgentWakePort` : wake_agent(project, agent, reason) — ne connaît PAS Tauri ; adapter
lance/rattache session structured/headless. **Lot B5.**
## Contrats/DTO
`InboxItem` { id, agent_id, source: Human|Agent{id}|BackgroundTask{task_id}|System,
kind: UserMessage|AgentDelegation|BackgroundCompletion|ResumeNotice, body, created_at_ms,
correlation_id?, priority (FIFO défaut, pas de priorité cachée V1) }.
`BackgroundCompletionDto` camelCase { taskId, ownerAgentId, projectId, kind, status,
exitCode, stdoutTail, stderrTail, finishedAtMs }.
Events `DomainEvent` : BackgroundTaskStarted/Progress(borné)/Completed/Failed/Cancelled,
AgentInboxQueued/Drained, AgentWakeScheduled/Started/Failed. (Events = observabilité/UI ;
store+mailbox = autorité.)
## Flux nominal run_in_background
1 agent lance commande → 2 crée BackgroundTask{owner,Running} → 3 adapter démarre → 4 tour
peut finir → 5 commande finit plus tard → 6 completion sink reçoit exit/stdout/stderr →
7 écrit Completed/Failed dans store → 8 enqueue InboxItem::BackgroundCompletion → 9 si owner
Idle: AgentWakePort.wake_agent démarre nouveau tour headless avec résultat → 10 si Busy/Waiting:
FIFO, drainé au prochain tour libre. **Idempotence : 1 seule completion livrée par task_id ;
crash entre store et wake réparé par reconcile.**
## Mailbox bornée
1 par agent, FIFO stricte, capacité configurable (`IDEA_AGENT_INBOX_CAPACITY`, défaut 100).
Enqueue pendant Working/Waiting → `queued` (plus jamais `busy`). Overflow : messages
humains/agents → `InboxFull` typée ; complétions de tâches → persistées delivery_pending,
JAMAIS perdues. « Busy » = tour en cours, pas entrée refusée.
## Lots backend
- **B1** domaine : types, ports Store/Runner, events, invariants purs. ✅ FAIT (12 tests).
(AgentInbox/AgentWakePort reportés à B4/B5.)
- **B2** store+registry : adapter FS/sqlite-like simple, écriture atomique, reconcile boot
(Running sans handle vivant → Unknown/Failed ou delivery_pending).
- **B3** completion sink : runner publie complétions sur canal interne ; sink persiste AVANT
tout wake ; tests idempotence double completion.
- **B4** mailbox unifiée : étendre `InputMediator`/`AgentMailbox` (pas de 2e FIFO concurrente) ;
enqueue_message, snapshots workstate ; remplacer refus « still busy » par `queued`.
- **B5** wake owner : adapter `AgentWakePort` au-dessus de `StructuredSessions`/
`AgentSession::send` ; wake seulement si idle ; sinon launch/rattach headless ; résultat
injecté comme message système explicite.
- **B6** rendezvous-as-task : `idea_ask_agent` reste synchrone pour l'appelant mais son
exécution interne = BackgroundTask{HeadlessRendezvous} ; timeouts/backstops → résultats de
tâche, plus des états invisibles.
- **B7** reconcile boot : lire store, ré-enqueue complétions non livrées, recalculer live-state.
## Lots frontend
- **F1** workstate : queue depth par agent, « Queued » au lieu de « busy rejected ».
- **F2** panel tâches de fond : liste par agent running/completed/failed ; cancel/open output/retry.
- **F3** agent cell : badge « messages en attente » + « tâche de fond terminée » ; pas de
transcript brut auto-injecté.
- **F4** notifications : toast sobre à la fin d'une tâche longue ; clic ouvre owner/détail.
## Invariants
completion persistée avant wake ; livrée au plus une fois ; aucun message vers agent connu
rejeté pour Busy ; mailbox ne dépasse jamais capacité ; overflow ne perd jamais une completion
système ; 1 item traité à la fois ; live-state = projection jamais autorité ; `Final` reste le
seul terminal normal headless ; un redémarrage n'oublie pas les complétions persistées non
drainées.
## Critères QA (backend)
commande background finissant après le tour → owner réveillé avec exit code + résumé ; idem
avec IdeA redémarré entre fin et wake → completion retrouvée ; message user à agent busy →
`queued` ; deux agents vers même agent busy → FIFO ; mailbox pleine → `InboxFull` sur message
normal, completion système en pending ; double event même task_id → 1 livraison ; annulation →
`Cancelled`, pas de wake succès ; rendezvous silencieux → backstop = tâche Failed/NoReply,
libère la queue ; session-limit resume continue et ne contourne pas la mailbox.
Liens : [[checkpoint-b2-bootstrap-applied-await-codex-reset-1430]],
[[rendezvous-no-reply-backstop-design]], [[session-limit-handling-design]],
[[headless-interagent-conversation-objective]], [[inter-agent-live-context-shared-per-agent]].

View File

@ -0,0 +1,34 @@
---
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

@ -0,0 +1,34 @@
---
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

@ -0,0 +1,62 @@
---
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

@ -0,0 +1,45 @@
---
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

@ -0,0 +1,47 @@
---
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

@ -0,0 +1,24 @@
---
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

@ -0,0 +1,46 @@
---
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

@ -0,0 +1,88 @@
---
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

@ -0,0 +1,37 @@
---
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

@ -0,0 +1,54 @@
---
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

@ -0,0 +1,40 @@
---
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

@ -0,0 +1,29 @@
---
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

@ -0,0 +1,98 @@
---
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

@ -0,0 +1,54 @@
---
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

@ -0,0 +1,42 @@
---
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

@ -0,0 +1,38 @@
---
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

@ -0,0 +1,38 @@
---
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

@ -0,0 +1,34 @@
---
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

@ -0,0 +1,34 @@
---
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

@ -0,0 +1,64 @@
---
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

@ -0,0 +1,60 @@
---
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

@ -0,0 +1,62 @@
---
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,29 @@
---
name: conversation-log-ls6-rotation-and-paginated-read
description: Contrat figé de la rétention/rotation du transcript et de la lecture paginée riche (surface humaine).
metadata:
type: reference
---
# LS6 — Rotation transcript + lecture paginée
Hygiène de persistance du `log.jsonl` + surface de lecture humaine paginée (viewer LS7).
## Invariant pivot INV-LS6
La rotation n'élague/déplace JAMAIS un tour d'id ≥ `up_to` du handoff courant : le tour up_to + tous les postérieurs restent dans le segment ACTIF. Sans handoff (ou up_to nil) ⇒ aucune rotation. Garantit que `ConversationLog::read(since=up_to)` (fold incrémental) et la reprise restent corrects après rotation. Motif : `read(since)` cherche le curseur par position ; retirer up_to du fichier casserait le fold.
## Rotation
- Stratégie = **archive segmentée** (`log.jsonl` actif + `log.1.jsonl`… anciens), PAS troncature/suppression (transcript = surface humaine riche à préserver).
- Déclencheur **hors chemin chaud** : use case `RotateConversationLog` à la reprise/ouverture, best-effort, idempotent. L'`append` ne déclenche JAMAIS la rotation (zéro latence ajoutée).
- Seuils sur segment actif : `ROTATE_AFTER_TURNS=500` OU `ROTATE_AFTER_BYTES=1MiB`. Backstop disque `MAX_ARCHIVE_SEGMENTS=20` (drop du plus ancien seulement). Politique pure domaine `rotation_plan(...) -> Skip|Archive{keep_from=up_to}`.
- Mécanique : verrou conversation bref ; réécriture actif **atomique en dernier** (tmp+rename) ; aucun tour perdu ( actif+archives) ; pagination dédoublonne par TurnId (crash-safe).
## Lecture paginée (port ISP `ConversationArchive`, impl FsConversationLog)
- `page(conversation, PageCursor{anchor,direction Forward|Backward}, limit)``TurnSlice{turns, has_more}`. limit clampé [1,200] défaut 50. Ordre chrono croissant. Archive-aware.
- Use case `ReadConversationPage` → DTO humain `TurnPage{turns:[TurnView{id,at_ms,role,source,text COMPLET,text_len}], has_more, next_anchor}`. **Texte complet, non borné, non distillé** = surface HUMAINE.
- `ConversationLog` (append/read/last) inchangé = vue segment actif (chemin chaud + dérivation).
## Frontière
Lecture riche consommée UNIQUEMENT par la commande Tauri du viewer humain, jamais par compose_convention_file/handoff/agent. Rotation ne touche que le transcript brut, jamais le handoff/injection.
## Frontend
LS6 = backend + commande Tauri `read_conversation_page`. Tout le React (viewer) = LS7.

View File

@ -0,0 +1,49 @@
---
name: conversation-rotation-safety-design
description: memory note conversation-rotation-safety-design
metadata:
type: project
---
---
name: conversation-rotation-safety-design
description: Cadrage initial pour la compression/rotation automatique non interruptive des conversations d'agents.
metadata:
type: project
---
# Conversation Rotation Safety Design
Objectif : reduire le cout token des conversations longues sans degrader la stabilite des agents ni les contacts inter-agents.
Socle existant a reutiliser :
- log canonique `.ideai/conversations/<conversationId>/log.jsonl` ;
- `handoff.md` incremental ;
- injection du handoff au lancement/relaunch ;
- `LeafCell.conversation_id` = id logique IdeA de paire, distinct du resumable provider ;
- `providers.json` pour `(pair_conversation_id, provider_key) -> engine_session_id` ;
- `InputMediator.busy_state(agent)` et FIFO par agent ;
- `ask_agent` avec lock de tour par agent + wait-for graph anti-deadlock ;
- attach/detach cellule deja modelise : la cellule est une vue, `TerminalSessions::rebind_agent_node` existe ;
- frontend write-portal sait deja compter la saisie humaine et declarer `set_front_attached`.
Regle produit centrale : rotation automatique opportuniste, jamais interruptive. IdeA ne compacte/rote une session qu'a un point sur.
Conditions minimales avant rotation :
- agent `Idle` (`InputMediator.busy_state == Idle`) ;
- aucune delegation/ticket/reply en cours ;
- aucun contact entrant en cours, sinon queue ou ancienne session jusqu'a bascule ;
- checkpoint durable OK : prompt/response appendes au log + `handoff.md` a jour ;
- cellule stable : pas d'attach/detach ou changement de layout en cours ;
- utilisateur non en train d'ecrire : focus/buffer non vide/frappe recente/IME composition/prompt interactif detectable ;
- nouvelle session demarree detached/background et prete avant bascule ;
- bascule atomique routing logique + attachement cellule ; ancienne session retiree ensuite.
Etat cible conceptuel :
`RotationRequested -> WaitForAgentIdle -> WaitForNoDelegation -> WaitForNoIncomingRoute -> WaitForCellStable -> WaitForUserInputClear -> Checkpointing -> StartReplacementDetached -> AttachReplacementToCell -> SwitchRouting -> RetireOldSession`.
Premier lot recommande : fondation non destructive.
- Ajouter modeles/policy de `ConversationRotation` et raisons de blocage.
- Ajouter query/use case d'evaluation qui retourne `Ready` ou `Blocked(reasons)` sans tuer ni relancer.
- Exposer les signaux manquants de cellule/saisie depuis le frontend vers backend, d'abord comme etat consultable.
- Publier des events de statut de rotation uniquement informatifs.
- Ne pas implementer la bascule physique avant que les tests de surete soient verts.

View File

@ -0,0 +1,26 @@
---
name: conversation-viewer-ls7-frontend
description: Contrat figé du viewer de transcript paginé (frontend pur, lecture seule, surface humaine).
metadata:
type: reference
---
# LS7 — Viewer fil-par-paire (front pur)
Dernier lot fonctionnel du programme persistance. UI humaine qui rejoue le transcript par paire, consomme la commande LS6 `read_conversation_page`. Lecture seule, zéro impact backend/agent.
## Gateway / adapter / mock (patron WorkStateGateway)
- Port `ConversationGateway.readPage(projectId, conversationId, {anchor?, direction?, limit?}) -> TurnPage`. Ajouter `conversation` à `Gateways`.
- Types domaine : `TurnView{id, atMs, role: prompt|response|toolActivity, source: {kind:human}|{kind:agent,agentId}, text COMPLET, textLen}`, `TurnPage{turns, hasMore, nextAnchor}`.
- Adapter `TauriConversationGateway` → invoke("read_conversation_page",{projectId,conversationId,cursor:{anchor,direction},limit}) + `conversationNormalization.ts` (mapper source Human/Agent calqué sur workStateNormalization). Mock avec pagination réelle + `_setTurns` pour tests offline.
- Frontière : composant → useGateways().conversation → adapter → invoke. Jamais d'invoke direct.
## Modèle d'affichage
- Clé = conversationId. Entrée = drill-down depuis le Work panel (`ConversationWorkSummary.conversationId` déjà énuméré ; rendre les lignes cliquables via prop `onOpenConversation`). Pas de nouvel appel « liste conversations ».
- Rejeu chrono croissant ; distinction sobre User↔Agent vs Agent↔Agent (parties déduites des sources, noms résolus depuis l'inventaire agents) ; toolActivity atténué/replié.
- Pagination : ouverture backward/None = dernière page (bas du fil) ; scroll-up = backward ancré sur le tour le plus ANCIEN du buffer (préfixe, dédup par id, hasMore gate) ; refresh queue = forward ancré sur le plus récent (manuel ou sur domain events delegationReady/orchestratorRequestProcessed).
## Intégration
- État local `viewerConversationId` dans ProjectsView ; swap main-area (rend ConversationViewer à la place de LayoutGrid, PAS un nouveau kind backend) ; bouton retour ; reset au changement de projet. viewerConversationId=null ⇒ UI actuelle inchangée (non-régression terminal).
## Frontière / backend
Lecture seule (read_conversation_page LS6, hors chemin chaud), jamais injecté dans un contexte agent. **Aucune part backend** : juste vérifier la signature de la commande exposée et aligner l'adapter si écart.

View File

@ -0,0 +1,52 @@
---
name: develop-realigned-to-cli-ui-baseline-2026-07-02
description: memory note develop-realigned-to-cli-ui-baseline-2026-07-02
metadata:
type: project
---
# develop réaligné sur la ligne UI CLI (pre-chat-ui-baseline) — 2026-07-02
**Type :** décision de topologie, validée utilisateur.
## Contexte / erreur corrigée
La feature « annonces inter-agent + fix Final Codex » avait été branchée par erreur sur
`develop` @ `0072aff`, qui portait le chantier **canonical-conversation / chat** (LC1→LC5).
Or l'UI de référence de l'utilisateur est la **ligne CLI** portée par
`feature/pre-chat-ui-baseline` @ `a9653bc` (UI CLI + commit « délégation toujours headless,
jamais d'injection PTY »). Le rebuild sur develop avait régressé l'UI (plus de terminaux CLI).
De plus, `a9653bc` — prémisse runtime de l'overlay — n'était QUE sur pre-chat-ui-baseline.
## Opération effectuée (Git, réversible, locale, aucune sortante)
1. Secours du chantier chat : branche `snapshot/develop-canonical-conversation-0072aff` +
tag homonyme → `0072aff` (récupérable à 100%).
2. `git branch -f develop feature/pre-chat-ui-baseline`**develop == `a9653bc`** (arbre
exactement celui de la ligne CLI). Le chantier chat est SUPERSÉDÉ sur la mainline develop
mais non détruit.
3. Nouvelle branche de fix : **`feature/inter-agent-announcements-v2`** depuis le nouveau
develop (@ a9653bc).
Retour arrière : `git branch -f develop snapshot/develop-canonical-conversation-0072aff`.
## État des refs
- `develop` = `a9653bc` (base de travail canonique désormais = ligne CLI).
- `feature/inter-agent-announcements-v2` = base de travail pour reporter les fix.
- `feature/inter-agent-announcements` = `71d307d` : ancien commit B0-B3 (basé sur l'ancien
develop chat), conservé pour cherry-pick.
- `snapshot/develop-canonical-conversation-0072aff` = chantier chat préservé.
## Conséquences pour la suite
- Reporter **B1/B2/B3** sur `feature/inter-agent-announcements-v2` (cherry-pick depuis
71d307d). **B0 devient probablement REDONDANT** : `a9653bc` (headless alongside/toujours
headless) est déjà la base — à vérifier avant de le rejouer.
- **Re-planifier F1/F2/F3** : le design frontend (preview cellule demandeur + overlay cellule
cible) avait été cadré contre le modèle de cellules canonical-conversation de develop ; sur
la base CLI (`a9653bc`), il faut re-cibler le modèle de cellules CLI/PTY réel. À faire
cadrer par Architect avant dev frontend.
- Rebuild AppImage à faire depuis cette base → restaure l'UI CLI + embarque les fix.
Liens : [[inter-agent-announcements-feature-and-codex-final-bug]],
[[inter-agent-live-context-shared-per-agent]].

View File

@ -0,0 +1,13 @@
---
name: f35-config-crud-delivered
description: 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.
metadata:
type: project
---
Ticket #35 F35.2 LIVRÉ (vert) sur `feature/modeles-locaux`. Débloqué par le contrat PLAT d'Architect.
**Contrat backend** : `list_model_servers` / `save_model_server({request:{config}})` / `delete_model_server({serverId})`. DTO plat camelCase `LocalModelServerConfig { id, kind:"llamaCpp", name, baseURL, port, modelPath?, servedModelName, binaryPath?, args, autoStart, stopPolicy }`. PIÈGE intégré : `save_model_server` exige un UUID valide dans `config.id` même à la création (backend ne génère PAS l'id serveur, seulement le model.id interne caché) → le front minte l'UUID client-side (`newModelServerId`). Erreur suppression référencée = `code:"model_server_in_use"`.
**Livré** : `ModelServerGateway` (port + adapter Tauri `adapters/modelServer.ts` + `MockModelServerGateway` avec `markInUse`). Feature `features/model-servers/` : `useModelServers` (CRUD, traduit in-use en message FR actionnable), `ModelServersPanel` (déclarer/éditer/supprimer), `ModelServerSelect` (dropdown binding avec « None » = serveur externe + préserve un id orphelin « unknown/removed »). Dans `FirstRunWizard`, le champ texte `localModelServerId` (F36) est remplacé par `ModelServerSelect`.
Cohérent avec F35.1 (badge corrèle via localModelServerId). tsc 0 ; suite 608/608. Sprint modèles locaux (F34 backend, F35, F36) désormais complet côté frontend.

View File

@ -0,0 +1,16 @@
---
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,17 @@
---
name: f36-multi-opencode-profiles-frontend
description: Multiplicité des profils OpenCode locaux côté UI first-run wizard — livrée, verte, sans gap backend.
metadata:
type: project
---
Ticket #36 (F36.1) livré côté frontend sur `feature/modeles-locaux`.
**Constat clé** : aucun gap backend. Le backend supporte déjà N profils OpenCode (identité = ProfileId) via `clone_opencode_profile_from_seed`, `list_profiles`, `save_profile`, `delete_profile`, `configure_profiles`. `OpenCodeConfig` DTO expose `localModelServerId` (camelCase).
**Ce qui manquait, purement front** : la commande clone n'était câblée dans aucun gateway, et le miroir TS `OpenCodeConfig` n'avait pas `localModelServerId`.
**Livré** : `ProfileGateway.cloneOpenCodeProfileFromSeed` (port + adapter Tauri + mock) ; le first-run wizard (`FirstRunWizard.tsx` + `useFirstRun.ts`) gère désormais une LISTE de profils OpenCode — bouton "Add OpenCode profile" + "Duplicate" par ligne, name éditable, cases reasoning/attachment, champ localModelServerId (saisie simple).
**Reste** : lot F35 = UI riche de config serveur local (remplacera la saisie simple de `localModelServerId`). Le wizard reste la surface de gestion de profils (`Settings ▸ Configure profiles` = `forceOpen`) ; il lit `firstRunState().referenceProfiles`, pas `list_profiles` — à vérifier au lot F35 pour l'édition de profils OpenCode déjà persistés.
tsc propre ; 62 tests first-run/mock verts ; suite complète 581/581.

View File

@ -0,0 +1,50 @@
---
name: feature-agent-skill-awareness-design
description: Design valide + decoupage de la feature « surfacer les skills assignes a un agent a la maniere MCP » (manifeste + idea_skill_read), a reprendre apres relance IdeA.
metadata:
type: project
---
# Feature : skills connus de l'agent « a la MCP »
Demarree le 2026-06-17. Branche Git **`feature/agent-skill-awareness`** (basee sur `develop` @ 8452333, qui contient deja le fix context-guard).
## ETAT 2026-06-17 (apres-midi) : slice backend T1->T5 FAIT, VERT, COMMITTE.
DevBackend a livre T1->T5, QA a couvert (23 tests, 1212 passed). Commits sur `feature/agent-skill-awareness` :
- `ab34363` feat(skill-awareness): T1->T5 (manifeste # Skills disponibles + outil MCP idea_skill_read, description+effective_description, use case ReadSkill, cablage state.rs, dump legacy conserve en mode sans-MCP).
- `1a10d67` fix(test): compteur d'outils MCP 11->12 (une 2e assertion codee en dur dans `crates/app-tauri/src/state.rs` ~l.2813 que QA avait ratee ; QA n'avait corrige que `infrastructure/tests/mcp_server.rs`).
- `e93a2c1` = cherry-pick du fix cold-start (cf. Bug 8 dans [[mcp-bridge-and-delegation-runtime-notes]]) — present aussi sur la branche dediee.
`cargo test --workspace` VERT sur l'arbre combine. **L'orchestrateur a committe lui-meme** (l'agent Git etait injoignable a cause du Bug 8) — A FAIRE RELIRE/REBASER PAR GIT une fois le canal restaure.
**RESTE :** T6 (champ description dans creation/edition skill cote front) + T7 (e2e : rebuild AppImage avec le fix Bug 8, relance, agent neuf + skill assigne -> voit le manifeste + appelle idea_skill_read). Puis Git decide les merges (feature->develop ; fix cold-start->develop+main).
## AJOUT 2026-06-17 (soir) : brief « capacites IdeA » INCONDITIONNEL — VERT, COMMITTE (566bff4)
Besoin utilisateur elargi : un agent neuf ignorait TOUT le perimetre IdeA (pas que les skills). Cas vecu : « agremente le contexte du projet » -> l'agent reinvente son propre systeme de contexte car le bloc `# Orchestration IdeA` ne parlait QUE de delegation. Fix (GO Architect, meme fonction pure `compose_convention_file` lifecycle.rs, zero port/entite) : ajout d'un brief « capacites IdeA » TOUJOURS present (decrit la CAPACITE, jamais le contenu -> survit a memoire/contexte vides), dans les 2 surfaces, AVANT le persona :
- mode MCP : nomme les outils contexte (`idea_context_read`/`idea_context_propose` avec semantique single-writer global HONNETE : proposition sans target = enregistree pour validation, PAS appliquee ; `idea_update_context` pour le .md d'un agent), memoire partagee (`idea_memory_read`/`idea_memory_write`), skills (`idea_skill_read`/`idea_create_skill`). Martele « le contexte projet d'IdeA EST le contexte, n'improvise jamais ton propre fichier ».
- mode non-MCP : MEMES concepts via fichiers `.ideai/` UNIQUEMENT (CONTEXT.md, memory/+MEMORY.md, skills .md), AUCUN nom d'outil `idea_*` (cloisonnement strict des 2 surfaces — sinon casse `mcp_prose_*`/`non_mcp_prose_*`).
QA : 5 tests dedies (brief inconditionnel des 3 capacites a zero contenu ; single-writer honnete ; non-MCP sans outil ; cloisonnement ; ordre avant persona). `cargo test -p application` = 0 failed (lib 52, agent_lifecycle 59). 1 assert existant adapte (`mcp_mode_without_skills_omits_section`). Commit atomique **566bff4** sur `feature/agent-skill-awareness` (Git a laisse les .ideai/ runtime hors commit). Merge feature->develop differe par Git jusqu'a T6+T7 (unite d'integration unique).
## Historique
Cycle initialement stoppe avant le code : la delegation MCP a wedge (Bug 7, puis Bug 8 residuel cf. [[mcp-bridge-and-delegation-runtime-notes]]).
## Besoin
Un agent neuf dans un projet neuf ignore les skills qui lui sont assignes (cas vecu : `build-appimage` assigne mais ignore, tout reinvente). Objectif : l'agent est **automatiquement au courant** de ses skills, comme il l'est des outils MCP, sans que l'utilisateur ait a le lui dire.
## Decision produit (utilisateur, 2026-06-17) : approche « Manifeste + idea_skill_read »
Diagnostic Architect : les skills sont DEJA injectes, mais (A) en VRAC (corps complet) en fin de `CLAUDE.md` -> lus comme de la doc, ignores ; (B) seulement au (re)lancement. On recadre « a la MCP » : affordances nommees+decrites en tete de contexte + chargement du corps a la demande.
- Bloc **« # Skills disponibles »** injecte JUSTE APRES le bloc « # Orchestration IdeA » (haute altitude), listant `**<name>** — <description>` ; prose imperative + renvoi a `idea_skill_read(name=…)`. Omis si zero skill.
- Nouvel outil MCP **`idea_skill_read(name)`** read-only, miroir exact de `idea_context_read`/`idea_memory_read` ; resout par nom (scope projet puis global), renvoie `content_md` inline ; erreur typee si introuvable/ambigu.
- Champ **`description: Option<String>`** sur l'entite `Skill` + helper `effective_description()` (fallback : 1ere ligne non vide du `content_md`, nettoyee du `#`). `#[serde(default)]` sur l'index (retro-compat `index.json` legacy obligatoire).
- Mode **sans MCP** (`profile.mcp` absent) : conserver l'ancien dump du corps complet (decision 4.2(b), zero regression).
## Decoupage (commits atomiques par tache verte, decides par Git)
- **T1 domaine** `crates/domain/src/skill.rs` : champ `description` + `effective_description()`.
- **T2 store** `crates/infrastructure/src/store/skill.rs` (+ application/skill) : `description` dans IndexEntry (`serde(default)`), propage via `CreateSkill`.
- **T3 convention-file** `crates/application/src/agent/lifecycle.rs` : section « # Skills disponibles » dans `compose_convention_file` (~l.2568, juste apres bloc Orchestration ~l.2586) ; alleger `resolve_skills` (~l.1202) pour n'utiliser que name+description (index, pas le corps) ; garder dump corps si non-MCP.
- **T4 outil MCP** `crates/infrastructure/src/orchestrator/mcp/tools.rs` + commande `OrchestratorCommand::ReadSkill { name, requester }` + methode `read_skill` dans `OrchestratorService` + petit use case `ReadSkill` (compose le port `SkillStore` existant, AUCUN nouveau port).
- **T5 cablage** `crates/app-tauri/src/state.rs` : injecter `ReadSkill` dans `OrchestratorService` (builder additif, comme le fix context-guard) + re-exports application (orchestrator/mod.rs + lib.rs).
- **T6 front (differable)** `frontend` : champ description dans creation/edition de skill.
- **T7 e2e** : rebuild AppImage + relance, agent neuf + skill assigne -> voit le manifeste + appelle `idea_skill_read`.
## Pieges (Architect)
Retro-compat `index.json` (serde default) ; resolution de nom ambigue (projet d'abord, erreur typee sinon) ; un skill assigne en cours de session reste invisible jusqu'au relaunch (limite inherente, comme MCP) ; pas de nouveau port, domaine = +1 champ, composition root seul point de cablage. GO Architect.

View File

@ -0,0 +1,11 @@
---
name: floatingwindow-focus-trap-mount-only
description: Le focus-trap de FloatingWindow ne doit dépendre que du mount ; sinon un onClose instable vole le focus à chaque frappe.
metadata:
type: reference
---
Le primitif `frontend/src/shared/ui/FloatingWindow.tsx` a un `useEffect` focus-trap qui appelle `(first ?? node)?.focus()`. Sa dépendance doit rester `[]` (mount-only), et `onClose` doit être lu via un `onCloseRef` maintenu à jour.
**Pourquoi** : les appelants (ex. `TicketDetail.requestClose`) passent souvent un `onClose` recréé à chaque render. Si l'effet dépend de `[onClose]`, chaque frappe dans un input contrôlé de la fenêtre → re-render → nouvelle identité `onClose` → l'effet se ré-arme → focus renvoyé au premier focusable → l'utilisateur ne peut taper qu'UNE lettre à la fois (bug #17, corrigé 2026-07-07).
**Comment l'appliquer** : ne jamais remettre `onClose` (ni une autre prop changeante) dans les deps de cet effet ; router les callbacks via une ref. Régression couverte par le test « #17 focus-loss bug » dans FloatingWindow.test.tsx. Voir [[ticket16-menus-floating-delivered-devfrontend]].

View File

@ -0,0 +1,15 @@
---
name: git-agent-push-access-gitea-ssh
description: memory note git-agent-push-access-gitea-ssh
metadata:
type: project
---
**CORRECTION (2026-06-23) — annule et remplace la note précédente : l'agent Git N'A PLUS l'accès push. Il est de nouveau STRICTEMENT LOCAL, comme avant.**
- Git gère **100 % du dépôt local** : commits, branches, merges/rebases locaux. Rien d'autre.
- **Aucune action sortante** : pas de `git push`, pas de PR distante, pas de publication de tags, pas de synchronisation remote. Ce périmètre n'est PAS dans ses responsabilités.
- Toute synchro avec un remote (`origin` Gitea ou autre) reste **hors périmètre Git** et sous décision/validation explicite de l'utilisateur, exécutée hors agent Git.
Le contexte d'agent `git.md` reflète déjà ce retour au strictement-local (garde-fou « tu restes strictement local, pas de `git push` »).
Voir [[git-owns-commit-merge-decisions]] (Git tranche toute la topologie LOCALE du dépôt).

View File

@ -0,0 +1,12 @@
---
name: git-owns-commit-merge-decisions
description: Ne jamais demander a l'utilisateur s'il faut committer/merger/brancher — c'est l'agent Git qui tranche toute la topologie du depot.
metadata:
type: feedback
---
Je ne dois PLUS demander a l'utilisateur s'il faut committer, merger, OU gerer les branches (creer/checkout/switch/rebase/supprimer une branche, ni quoi, ni quand). TOUTE la gestion des branches et la topologie du depot est decidee par l'agent **Git** — c'est LUI qui tranche.
**Why:** l'utilisateur a explicitement (CLAUDE.md §2.4 + confirme en session le 2026-06-17) defini Git comme garant du depot local : commits, merges, rebases ET toute la gestion de branches sont SA decision, pas celle de Main ni de l'utilisateur. Demander a l'utilisateur court-circuite ce role et le fait perdre du temps.
**How to apply:** quand un lot est vert, je delegue a Git (`idea_ask_agent` target=Git) en lui livrant l'etat (fichiers, tests verts, etat de compilation) et c'est Git qui decide/execute commit, merge, ET la branche (creer une `feature/*`, switch, rebase, supprimer apres merge…). Avant de demarrer une nouvelle feature, je passe la main a Git pour la decision de branche. En cas de doute sur le versioning/branching, je demande a **Git**, jamais a l'utilisateur. Les actions SORTANTES (push/publication) restent la seule chose soumise a validation explicite de l'utilisateur. Voir [[session-limit-handling-design]].

View File

@ -0,0 +1,22 @@
---
name: handoff-ls5-summary-bound-and-llm-seam
description: Contrat figé de la borne de handoff (perf) et du seam résumeur LLM non activé.
metadata:
type: reference
---
# LS5 — Borne handoff + seam LLM
Ferme le must-have perf du programme persistance : un `summary_md` non borné gonflait le contexte injecté à chaque lancement.
## Borne summary_md (déterministe, en CARACTÈRES, pas tokens)
- **Par tour** : `render_turn` tronque le texte aplati à `TURN_LINE_MAX_CHARS=240` (infra summarizer). Corrige le trou réel (un gros Response = ligne géante).
- **Totale** : fn PURE domaine `bound_handoff_summary(Handoff, max)` + `HANDOFF_SUMMARY_MAX_CHARS=4096`. Stratégie de dépassement = **troncature distillée** (garde objectif + lignes les plus récentes, drop oldest, frontière de ligne). JAMAIS re-fold compactant, JAMAIS rejet (n'bloque jamais l'append du log). `up_to`/`objective` jamais modifiés. Idempotent.
- **Appliquée à l'écriture** (`RecordTurn` après `fold`, avant `save` → borne universelle quel que soit le résumeur) **ET défensivement à l'injection** (`resolve_handoff` avant compose → protège les `handoff.md` legacy non bornés, sans migration).
## Seam LLM : TRANCHÉ = « prêt mais NON activé »
- Pas de vrai LLM en LS5 : `fold` tourne sur le chemin chaud (par tour, dans la délégation) → un appel réseau là = régression perf interdite. Défaut runtime reste `HeuristicHandoffSummarizer`.
- Durcissement réel = la borne totale appliquée **dans RecordTurn (hors résumeur)** ⇒ un futur `LlmHandoffSummarizer` ne peut pas exploser le budget contexte.
- Contrat futur adapter LLM (documenté) : déclenchement **froid/hors chemin** (reprise/rotation/débounce, jamais par tour) ; timeout + **fallback heuristique** (trait sans `Result`) ; sélection par flag, défaut heuristique. Trait `HandoffSummarizer::fold` inchangé.
## Frontière
Transcript = `log.jsonl` (jamais injecté). `summary_md` = dérivé distillé, désormais borné à l'écriture et à l'injection. Conforme « surface agent = borné/distillé ».

View File

@ -0,0 +1,40 @@
---
name: headless-interagent-conversation-objective
description: memory note headless-interagent-conversation-objective
metadata:
type: project
---
# Objectif chantier — remplacer la conversation inter-agent MCP par headless robuste
## Intention produit
Le projet veut se séparer du MCP pour la **conversation inter-agent**, car le rendez-vous MCP a provoqué trop de blocages, wedges, busy fantômes et pertes de résultats. MCP reste conservé pour les autres outils IdeA : mémoire, liste d'agents, contexte, workstate et fonctions non conversationnelles.
Le nouveau mécanisme doit utiliser les modes **headless** fournis par les modèles/CLIs comme interface de communication entre agents, tout en gardant le modèle mental : **1 agent = 1 employé**.
## Règles fonctionnelles validées
- Un agent n'a qu'une seule conversation canonique et une seule identité opérationnelle, qu'il soit utilisé via la cellule CLI par l'utilisateur ou via headless par un autre agent.
- Quand un agent B travaille pour un agent A, aucun autre agent ni l'utilisateur ne peut lui parler tant que B n'a pas fini.
- L'utilisateur doit pouvoir voir que B est occupé et, si possible, suivre le travail headless en temps réel. La solidité prime sur cette UI temps réel.
- L'utilisateur doit pouvoir cancel le travail d'un agent occupé.
- Si l'utilisateur annule A dans la CLI alors que A attend B, l'annulation doit cascader vers B.
- B ne peut être annulé que par l'agent qui lui parle ou par l'utilisateur, pas par un autre agent tiers.
- Si plusieurs agents veulent parler à B, les demandes attendent en FIFO simple jusqu'à ce que B soit libre.
- Le headless est seulement l'interface de communication agent-agent : mêmes mémoire, contexte, historique, permissions, cwd et outils qu'en usage CLI interactif.
- Un historique reconstitué doit être accessible depuis la cellule, via un bouton, avec toutes les conversations de la session dans un historique unique.
- L'architecture reste hexagonale : conversation canonique par modèle/adapters, pas de dépendance directe dispersée aux formats natifs.
## Priorité de conception
Priorité 1 : robustesse et absence de blocage durable.
Le design doit privilégier des garanties mécaniques simples : processus headless borné, fin par exit process, timeout, cancel explicite, nettoyage d'état idempotent, queue FIFO observable, et résultat synthétique en cas d'échec.
Priorité 2 : observabilité et UX.
L'affichage temps réel du travail headless est souhaité si le mode headless permet de streamer stdout/stderr ou événements structurés, mais ne doit pas fragiliser le protocole. À défaut, fournir statut occupé, bouton cancel, historique final et diagnostic exploitable.
## Décision de périmètre
Le MCP n'est pas retiré globalement. Il est retiré uniquement du chemin critique de conversation inter-agent. Les outils IdeA existants peuvent rester exposés aux agents via MCP tant qu'ils ne servent pas au rendez-vous conversationnel.

View File

@ -0,0 +1,14 @@
---
name: idea-program-surface-separation-and-livestate
description: Cadrage du programme post-skills : ce qui existe vs reste, et la règle de frontière surface-agent/humaine.
metadata:
type: project
---
État au cadrage (develop @ 827d477) :
- **#2a handoff incrémental cross-profile = FAIT + CÂBLÉ** (lots P1P8) : `domain/conversation_log.rs` (`Handoff`, `HandoffStore`, `HandoffSummarizer::fold` incrémental, `ProviderSessionStore`), `application/conversation/record.rs` (`RecordTurn` = append+fold), wiring `state.rs` (`AppRecordTurnProvider`), injection au lancement via `HandoffProvider` (P7). Résumeur = `HeuristicHandoffSummarizer`, seam async pour `LlmHandoffSummarizer` (P10) déjà en place. Reste : seam LLM + borne `summary_md`.
- **#2b log canonique = FAIT** : `ConversationLog` append-only `.ideai/conversations/<id>/log.jsonl`, **jamais injecté à un agent** (doc domaine explicite). Reste : rétention/rotation + lecture paginée UI.
- **#1 live-state agent = À CONSTRUIRE (cœur)** : aujourd'hui seul `GetProjectWorkState` (read-model HUMAIN dérivé, non durable). Construire un 4ᵉ store `live-state.json` (**gitignored, runtime**) : `domain/live_state.rs` (`LiveState`/`LiveEntry`/`WorkStatus`, port `LiveStateStore`, **keyed last-writer-wins, JAMAIS append**, champs bornés, `prune` TTL+max_n), use cases `UpdateLiveState`/`GetLiveStateLean`, adapter `FsLiveStateStore`, auto-update depuis `orchestrator/service.rs` (ask→Working, reply→Done), injection bornée `# État du projet` au lancement + outils MCP `idea_workstate_read`/`idea_workstate_set`. Ne stocke QUE le non-re-dérivable (intent/progrès/dernière délégation) ; busy/queue restent calculés.
**Règle de frontière gravée (testable)** : Surface AGENT = borné/distillé/pointeur uniquement (capacités, pointeurs mémoire, affordances skills, handoff `summary_md`, live-state lean). Surface HUMAINE = riche (ProjectWorkStatePanel, viewer fil-par-paire qui rejoue le log). **Transcript / append-only INTERDIT d'injection dans un contexte agent** ; seul un dérivé distillé franchit. 4 stores distincts : `memory/` (savoir stable, versionné) · `handoff.md` (reprise par fil) · `log.jsonl` (transcript humain) · `live-state.json` (coordination transitoire maigre).
Découpage : LS0 doc baseline → LS1 domaine live-state → LS2 store+usecases → LS3 auto-update délégation → LS4 injection+MCP (clôt cold-start) ; LS5 seam LLM+borne handoff, LS6 rétention log+lecture UI (parallèles) ; LS7 UX fil-par-paire (front pur) ; LS8 doc clôture.

View File

@ -0,0 +1,67 @@
---
name: inter-agent-announcements-feature-and-codex-final-bug
description: memory note inter-agent-announcements-feature-and-codex-final-bug
metadata:
type: project
---
# Annonces inter-agent (UI live) + fix du Final Codex — DESIGN FIGÉ
**Type :** design de feature + bug racine. Validé utilisateur le 2026-07-02, cadré par Architect.
## Bug racine (Codex)
`crates/infrastructure/src/session/codex.rs` : `parse_event` (~l.86) mappe CHAQUE
`item.completed{item.type=="agent_message"}` vers `ReplyEvent::Final`, et `send` (~l.234)
casse au PREMIER Final (`break 'lines`). Or `codex exec --json` émet plusieurs
`agent_message` par tour (préambule → outils → conclusion → `turn.completed`). IdeA
renvoyait donc le **préambule** au demandeur au lieu de la **conclusion**. Preuve live :
Architect répondait « je vais interroger QA… » au lieu du résultat. **Défaut d'implémentation,
pas du headless Codex** (un `codex exec` brut déroule tout le tour).
## Feature validée (le bug devient fonctionnalité)
- **Final** = DERNIER `agent_message` avant `turn.completed` → seule chose renvoyée au
demandeur (résout le ticket). Bords : 1 seul message (préambule=conclusion) ; 0 message
`TargetReturnedNoReply` (inchangé).
- **Annonces** = `agent_message` intermédiaires → nouvel événement NON terminal
`ReplyEvent::Announcement{text}`, poussé sur le bus vers l'UI, JAMAIS renvoyé au
demandeur, JAMAIS persisté au transcript (éphémère).
- **UI** : (a) cellule DEMANDEUR = petit cadre preview près de la drop-list d'agents,
filtré par `ticket_id` ; (b) cellule CIBLE si visible = overlay d'indisponibilité (texte
haut « un agent est en train de lui parler » + annonces défilantes au centre), monté sur
live-state Working, retiré au Final/idle (reste tant qu'≥1 ticket actif sur la cible).
## Contrat (Architect)
- `ReplyEvent::Announcement{text}` (non terminal) vs `Final{text}` (terminal, résout).
- `drain_with_readiness` : Announcement → publie event, ne résout pas, ne passe pas idle ;
Final → résout ticket + idle + fin du drain.
- Nouveau `DomainEvent::AgentAnnouncement{project_id, requester, target, ticket_id, text,
at_ms}` (attribution obligatoire pour router vers la bonne cellule + isoler projet/onglet).
- Overlay cible = état UI piloté par live-state (pas un blocage du PTY : le contact passe par
session headless séparée, `allow_structured_alongside_pty:true`).
- Généralisation Claude : `session/claude.rs` garde son terminal explicite (`result`) comme
Final ; messages complets non terminaux → Announcement ; NE PAS promouvoir les `TextDelta`
tokenisés (bruit) ; tool events restent `ToolActivity`.
## Découpage dev (Architect)
- **B1** domaine/appli : `ReplyEvent::Announcement`, `DomainEvent::AgentAnnouncement`,
`structured.rs`, `service.rs` (`ask_structured` ne termine que sur Final).
- **B2** Codex `codex.rs` : bufferiser le dernier `agent_message`, émettre les précédents en
Announcement, le dernier en Final à `turn.completed`.
- **B3** Tauri `app-tauri/{events,dto,state}.rs` : relay + DTO camelCase.
- **F1** front store/gateway annonces (index par ticket/target, borné ~20-50).
- **F2** front preview cellule demandeur.
- **F3** front overlay cellule cible.
- **Q** QA e2e : Main→Architect→QA, préambule+outil+conclusion ; Main ne reçoit que la
conclusion ; preview demandeur + overlay cible pendant le travail ; fermeture au Final.
Critère : reproduire le bug initial et constater la correction.
## État
Design figé, cadrage Architect complet. Reste : Git branche → B1/B2/B3 + F1/F2/F3 → QA.
Non démarré côté dev au 2026-07-02.
Liens : [[inter-agent-live-context-shared-per-agent]], [[rendezvous-no-reply-backstop-design]],
[[headless-interagent-conversation-objective]], [[conversation-viewer-ls7-frontend]].

View File

@ -0,0 +1,79 @@
---
name: inter-agent-live-context-shared-per-agent
description: memory note inter-agent-live-context-shared-per-agent
metadata:
type: project
---
# Contexte live inter-agent : PAR AGENT (partagé), pas par paire — DÉCISION FIGÉE
**Type :** decision d'architecture / produit — validée utilisateur le 2026-07-02.
## Décision
Le contexte live d'un agent IdeA est porté **par l'agent cible**, partagé entre TOUS les
demandeurs. Pour un `AgentId` donné, IdeA maintient **au plus une** session
headless/structurée vivante ; tous les `idea_ask_agent(requester, target)` vers le même
`target` réutilisent cette session, quel que soit le demandeur.
Ce partage est **intentionnel et souhaité**, pas un bug ni une fuite : tous les agents du
projet sont dans le même domaine de confiance (même utilisateur, même projet). Le contexte
live d'un agent = mémoire de travail d'équipe / tableau blanc partagé. On NE veut PAS
d'isolation par paire.
La paire `(requester, target)` n'est **pas** une frontière d'isolation du contexte moteur :
elle sert uniquement à l'attribution, la corrélation requête/réponse, les vues UI et les
filtres de transcript.
## Preuve empirique (2026-07-02)
Main a confié à QA le token `IDEA-TOKEN-7F3A-BLEEDCHECK` ; Architect a ensuite pu le
récupérer auprès de QA **sans que Main le lui transmette**. Cause : `ensure_structured_session`
(`crates/application/src/orchestrator/service.rs:1948`) fait un early-return sur
`session_for_agent(&agent_id)` → une seule session vivante par agent, réutilisée.
## Modèle de transcript cible (cadré par Architect)
**Log canonique PAR AGENT + vues par paire dérivées.** Abandon du transcript canonique
par paire comme source de vérité (il promet une isolation qui n'existe pas en live).
- Arbo cible : `.ideai/conversations/agents/<targetAgentId>/{log.jsonl, handoff.md, providers.json, log.N.jsonl}`
- Chaque tour porte l'attribution : `thread_id=Agent(target)`, `requester`, `target`,
`correlation_id`, `role`, `source`.
- Vues = projections filtrées (`ForAgent`, `ForPair`, `ForCorrelation`), pas des logs séparés.
Impacts à traiter :
- `resolve_conversation``resolve_agent_thread(target)` + `resolve_conversation_view(requester,target)`.
- `bind_conversation_session` → bind sur `targetAgentId` ; réutiliser la session existante.
- `ConversationRegistry` → index primaire `targetAgentId`, secondaires `requester`/`correlation_id` ;
interdire 2 fils live pour le même target.
- `ProviderSessionStore` clé `(agent_thread_id, provider_id)` au lieu de `(pair_id, provider_id)`.
- `LeafCell.conversation_id` = désormais **id de fil agent**, plus « id de paire ».
- Viewer LS7 : défaut = fil agent complet ; vue par paire = vue filtrée/partielle libellée comme telle.
## Garde-fou efficience (rotation multi-demandeurs)
Le design LS5/LS6 tient, mais un fil agent partagé **croît plus vite** (agrège les demandes
de plusieurs requesters). Ajustements : la rotation s'applique au fil agent canonique (pas
aux vues) ; le résumé/handoff doit conserver l'attribution minimale (`Objectif courant`,
`Demandes actives par requester`, `Décisions récentes`, `Blocages`, `Dernière réponse
corrélée`) ; transcript brut jamais réinjecté (humain-only) ; handoff borné à
`HANDOFF_SUMMARY_MAX_CHARS=4096`. Risque principal : dilution si demandeurs poussent des
objectifs contradictoires → mitigé par les rubriques stables du handoff.
## Découpage dev recommandé (Architect)
1. `ARCHITECTURE.md` §19.7 : remplacer « id de paire » par « fil agent partagé » (+ §16/§17/§21).
2. Introduire `ConversationThreadId` / `ConversationViewId`.
3. Adapter `resolve_conversation`, `bind_conversation_session`, `ConversationRegistry`.
4. Compatibiliser les anciens chemins `for_pair(requester,target)` comme vues historiques.
5. LS7 viewer : fil agent complet + filtres.
6. Test QA : un fait confié à QA par Main est visible quand Architect interroge QA.
## État
Décision figée. Cadrage architectural livré par Architect. Reste à : intégrer la proposition
dans `ARCHITECTURE.md`, puis planifier le dev (cycle normal Architect→Git→Dev→QA).
Liens : [[conversation-rotation-safety-design]], [[handoff-ls5-summary-bound-and-llm-seam]],
[[conversation-log-ls6-rotation-and-paginated-read]], [[conversation-viewer-ls7-frontend]],
[[headless-interagent-conversation-objective]].

View File

@ -0,0 +1,78 @@
---
name: issue-ticket-system-design
description: memory note issue-ticket-system-design
metadata:
type: project
---
---
name: issue-ticket-system-design
description: Cadrage figé (Architect+Main, 2026-07-02) du système de tickets IdeA façon Jira — domaine `Issue` par projet, exposé « ticket » côté UI/MCP, Carnet éditable, #N séquentiel. Fait autorité pour les lots T1-T6/F1-F7.
metadata:
type: reference
---
# Système de tickets IdeA (domaine `Issue`) — CADRAGE FIGÉ 2026-07-02
## Décisions produit verrouillées (utilisateur)
- **Portée PAR PROJET** : stockage dans `.ideai/tickets/` du projet (pas de backlog global).
- **Identifiant court `#42`** : compteur séquentiel par projet, parlable à l'oral (poignée
partagée humain↔agent, y compris dans une délégation `idea_ask_agent`).
- **Champ de connaissances éditable = « Carnet »** (PAS « mémoire » — évite collision avec la
mémoire projet). Markdown éditable/réorganisable, scoped ticket, pas append-only.
- **Stockage Markdown + frontmatter**, un DOSSIER par ticket.
- **V1 SANS attachments** : livrer T1-T5 + F1-F5 + F7 ; attachments (T6/F6) en fast-follow.
## Nommage (collision évitée avec le TicketId de délégation)
Domaine/code = **`Issue`** (`IssueId`, `IssueNumber`, `IssueRef("#42")`, `IssueStore`,
modules `domain::issue`/`application::issues`/`infrastructure::issues`). UI + MCP public =
« ticket » (`idea_ticket_*`, DTO camelCase). Ne JAMAIS nommer `Ticket` en code (réservé à la
délégation inter-agent).
## Frontière Carnet vs mémoire projet
Carnet = savoir DU ticket (décisions locales, hypothèses, investigation, contraintes). Mémoire
projet = savoir transverse durable. Règle : si l'info doit survivre à la fermeture du ticket et
guider d'autres travaux → mémoire projet ; sinon → carnet.
## Modèle domaine
`Issue { id(uuid), number(u64), title, description(md), status, priority, carnet, links,
agent_refs, attachments, created_by/updated_by(IssueActor: User|Agent|System),
created_at/updated_at, version(optimistic) }`.
- `IssueStatus`: Open | InProgress | Qa | Closed (DTO: open|inProgress|QA|closed).
- `IssuePriority`: Low | Medium | High | Critical.
- `IssueLinkKind`: RelatesTo | Blocks | BlockedBy | Duplicates | DependsOn.
- `AgentIssueRef { agent_id, role: Assigned|Mentioned|Reviewer|Owner }`.
Invariants : number>0 unique/projet ; IssueRef = `#<u64>` ; titre non vide ; pas de self-link ;
assignation → AgentId connu du manifeste ; toute écriture incrémente version ; attachments sous
le dossier du ticket, pas de `..`/symlink/chemin absolu.
## Ports
`IssueStore` (create/get_by_ref/list(filter)/update(expected_version)/read_carnet/
write_carnet(expected_version)) ; `IssueNumberAllocator` (allocate_next, atomique via
counter.json + counter.lock + rename, jamais de réutilisation de numéro) ; `IssueAttachmentStore`
(add/remove/list — lot attachments). Adapters : `FsIssueStore`, `FsIssueNumberAllocator`,
`FsIssueAttachmentStore`, `McpIssueTools`, `TauriIssueCommands`, `TauriIssueEventRelay`.
## Surface MCP (agents)
`idea_ticket_create/read/list/update/update_status/update_priority/read_carnet/update_carnet/
link/unlink` (+ `idea_ticket_attachment_*` au lot attachments). DTO camelCase ; `TicketRef` =
`#${number}` ; concurrence via `expectedVersion` sur chaque écriture.
## Events domaine (→ projection UI, même modèle events→front B-series)
IssueCreated/Updated/StatusChanged/PriorityChanged/CarnetUpdated/Linked/Unlinked/
AgentAssigned/AgentUnassigned/AttachmentAdded/Removed/StorageConflictDetected.
## Layout stockage
`.ideai/tickets/{counter.json, index.json(projection reconstructible), <N>/{issue.md(frontmatter
+description), carnet.md, attachments/}}`. Attachments versionnés git par défaut (warning >5MiB,
refus configurable >25MiB, pointeur URI pour les gros).
## Lots
Backend : T1 domaine Issue · T2 store FS Markdown (+allocator) · T3 use cases (Create/Read/List/
Update/UpdateCarnet/Link/AssignAgent, optimistic concurrency) · T4 surface MCP `idea_ticket_*` ·
T5 commands Tauri + relay events · T6 attachments (fast-follow).
Frontend : F1 gateway UI (`IssueGateway`, pas d'invoke direct) · F2 liste filtrable · F3 détail/
édition (gestion conflits expectedVersion) · F4 éditeur Carnet Markdown · F5 liens & assignations ·
F6 attachments (fast-follow) · F7 `#42` cliquable + pré-remplissage délégation.
Réutilise : store FS par projet façon `FsBackgroundTaskStore`/`AppLiveStateProvider`, EventBus +
TauriEventRelay, pattern gateway UI.
Lien : [[background-tasks-first-class-design]], [[agent-context-memory-and-profile-handoff]].

View File

@ -0,0 +1,15 @@
---
name: live-state-persistence-program-closed-ls8
description: Le programme live-state + persistance conversationnelle est livré et documenté ; pointe la doc de clôture et les points restés ouverts.
metadata:
type: project
---
Programme **live-state / persistance conversationnelle CLOS** (LS1→LS7 livrés @ fd7adbb ; LS8 = doc de clôture).
**Doc de référence** : `docs/LS8-live-state-persistence-closure.md` + `ARCHITECTURE.md` §21 (cartographie des 4 stores) ; §19 retitré « LIVRÉ » ; §14.1 et §18.5 corrigés (catalogue MCP **14**).
**4 stores disjoints** : `.ideai/memory/` (savoir stable, versionné) · `handoff.md` (reprise distillée bornée ≤4096) · `log.jsonl` (transcript humain riche, JAMAIS injecté) · `live-state.json` (coordination maigre runtime, gitignoré). Surface AGENT bornée/distillée/pointeur ; surface HUMAINE riche ; seul le handoff distillé franchit vers un contexte agent.
**Restant ouvert** : (1) activation seam LLM `LlmHandoffSummarizer` (non activé, défaut heuristique, contrat ADR LS5) ; (2) sweep périodique de rotation (idempotent, non câblé) ; (3) **discordance D19-4 ↔ .gitignore** : `.ideai/conversations/` devait être gitignoré mais est suivi — à trancher Git/Main ; (4) intégration MCP e2e UX ; (5) multi-fenêtres registre sessions ; (6) auto-update mémoire/contexte en cours de session.
**Contrainte d'écriture** : un agent lancé en run-dir isolé (`.ideai/run/<id>/`) **ne peut pas écrire l'arbre du project root** (ARCHITECTURE.md, docs/) — les modifs de doc passent par Git (write+commit authority).

View File

@ -0,0 +1,21 @@
---
name: live-state-reboot-reconciliation-design
description: memory note live-state-reboot-reconciliation-design
metadata:
type: project
---
---
title: Réconciliation du live-state au reboot (ReconcileLiveState)
type: reference
description: Décision d'architecture pour réconcilier les lignes live-state fantômes au redémarrage — seam, source de vérité, contrat de statut et préservation du self-only.
---
**Problème** : au reboot, `.ideai/live-state.json` n'est pas réconcilié → agents fantômes `working/waiting/blocked` alors que leurs sessions sont mortes. `prune` (TTL 6h) ne couvre pas le fantôme récent.
**Décision (cadrage Architect, 2026-06-23)** :
- **Seam** : étape best-effort `reconcile_live_state` dans la chaîne `open_project` (commands.rs), juste après `reconcile_layouts`. Pas d'app-boot global (live-state est par-projet). Pas d'outil MCP. Justification : un crash ne déclenche jamais `close_project`, donc **open est le seul filet fiable**.
- **Source de vérité** : le registre de sessions vivantes `LiveSessions` / trait `LiveAgentRegistry` (`application/src/terminal/registry.rs`) — la *même* vérité que `GetProjectWorkState`. Prédicat orphelin = `status ∈ {working,waiting,blocked}` ET `!is_agent_live`. Race-safe : tourne avant toute relance ; LWW gagne via `updated_at_ms` frais.
- **Contrat** : orphelin → `idle` (pas de nouveau statut, évite le ripple DTO/front). Garder `intent` (trace), vider `ticket` + `last_delegation` (rendez-vous mort, tracé ailleurs dans log/handoff), `progress` = marqueur stale, `updated_at_ms` frais.
- **Pas de nouveau port.** Use case applicative `ReconcileLiveState` (compose `LiveStateStore` + `LiveAgentRegistry` + `Clock`) + transformation **pure** `LiveState::reconcile_orphans(is_live, now)` dans `domain/src/live_state.rs`. Provider par-root côté app-tauri (calqué sur `LiveStateProvider`/`live_state_for`).
- **Self-only de `idea_workstate_set`** : invariant **de la surface MCP**, pas du store. `set_workstate` lie `agent_id`=identité handshake ; `UpdateLiveState`/`LiveStateStore` sont identity-agnostic. La réconciliation est un **acte système** dans le composition root qui appelle le port directement, **jamais** via `OrchestratorCommand::SetWorkState` → self-only préservé par construction. Même split que `snapshot_running_agents`/`reconcile_layouts`.
Fichiers probables : `domain/src/live_state.rs`, `application/src/workstate/{mod.rs,reconcile.rs}`, `app-tauri/src/{lib.rs,state.rs,commands.rs}`. Voir [[live-state-persistence-program-closed-ls8]], [[handoff-ls5-summary-bound-and-llm-seam]].

View File

@ -0,0 +1,47 @@
---
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

@ -0,0 +1,45 @@
---
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

@ -0,0 +1,33 @@
---
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

@ -0,0 +1,29 @@
---
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

@ -0,0 +1,24 @@
---
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

@ -0,0 +1,37 @@
---
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,35 @@
---
name: opencode-llamacpp-replaces-ollama
description: memory note opencode-llamacpp-replaces-ollama
metadata:
type: project
---
---
title: OpenCode local provider — llama.cpp remplace Ollama (chantier livré)
type: decision
description: Le provider local d'OpenCode passe d'Ollama à llama.cpp (llama-server OpenAI-compatible). Profil éditable baseURL/apiKey/model. Livré sur develop (merge 2e98f1f). Clôt le diagnostic tool-calling Ollama.
---
# OpenCode local : llama.cpp remplace Ollama (2026-07-11)
## Pourquoi
Le tool-calling des modèles locaux via **Ollama** ne s'est jamais déclenché nativement en live : OpenCode fuyait les appels d'outils en texte `<function=...>` (émulation par prompt), jamais parsés. Diagnostic utilisateur : la faute est dans la relation **OpenCode↔Ollama**. Décision : abandonner Ollama comme provider OpenCode et passer à **llama.cpp** (`llama-server`, endpoint OpenAI-compatible). Voir historique : [[opencode-config-model-agnostic-tool-diagnostic]], [[opencode-ollama-native-tool-call-flag]], [[opencode-ollama-tool-calling-surface-overload]] (contexte Ollama, désormais superseded).
## Contrat livré
`OpenCodeConfig` (domaine + DTO app-tauri + type frontend) :
`{ baseURL: String (requis, http/https), apiKey: Option<String>, model: String (requis), reasoning: Option<bool>=true, attachment: Option<bool>=false }`. Sérialisation wire camelCase (`baseURL` via serde rename), `apiKey`/`reasoning`/`attachment` `skip_serializing_if=None`.
Seed profil canonique : `opencode-ollama`**`opencode-llamacpp`** ("OpenCode + llama.cpp"), command `opencode`, adapter `OpenCode`, defaults `baseURL=http://localhost:8080/v1`, `apiKey=sk-no-key`, `model=qwen3-coder-30b`.
`opencode_config_json` (crates/application/src/agent/lifecycle.rs) régénère un opencode.json MINIMAL : provider `llamacpp` (`npm=@ai-sdk/openai-compatible`, `options.baseURL/apiKey` du profil, def modèle `llamacpp/<model>` avec `tool_call:true,reasoning,attachment`), MCP `idea` inchangé, `permission bash/edit=ask`, `disabled_providers=["anthropic","openai","gemini","ollama"]`. `apiKey` omis (pas `null`) si absent. Plus aucun résidu `ollama`/préfixe `ollama/`/allow-list diagnostic.
Frontend : wizard profil OpenCode = 3 champs éditables **Base URL / Model / API key(optionnel)** (`FirstRunWizard.tsx`, `profile.ts`, mocks). L'embedder Ollama (`ollamaDetected`, mémoire vectorielle) est un AUTRE usage, NON touché.
## État
- Fichiers : domain/profile.rs, application/{catalogue.rs,lifecycle.rs,tests/agent_lifecycle.rs}, infrastructure/session/opencode.rs ; frontend domain/index.ts, adapters/mock/*, features/first-run/*.
- QA VERT : domain 244, application 81+64, infra 263/10 (les 10 = bind-port sandbox, identiques sur develop = non-régression), frontend 574, tsc propre. Claude/Codex non régressés.
- Git : commit `4e70631`, merge `--no-ff` `2e98f1f` sur `develop`. Base branche = `eaba05d` (profil OpenCode process-backed). WIP diagnostic Ollama capsulé dans `3cdedf2` sur `feature/opencode-glm47-flash-tool-diagnostic`. PAS de push distant.
- Tickets : #32 fermé ; #42/#43 (Ollama) retirés du store.
## Reste ouvert
E2E live llama.cpp jamais exécuté (aucun `llama-server` joignable sur :8080 au moment QA ; `llama-server` 9859 + `opencode` 1.17.18 installés). À valider côté utilisateur : lancer llama-server, relancer l'Appointe rebuild, créer un agent profil llama.cpp, vérifier un vrai `tool_use` MCP (pas de `<function=` texte). Rebuild AppImage requis pour le live (binaire qui tourne = AppImage). Build via `NO_STRIP=true` cf [[appimage-build-no-strip-relr-dyn-fix]].

View File

@ -0,0 +1,26 @@
---
name: permissions-sandbox-system-state
description: Etat du systeme de permissions/sandbox IdeA (domaine pur -> projection advisory -> enforcement OS Landlock sur PTY ET structure) et l'unique risque residuel.
metadata:
type: project
---
# Systeme de permissions / sandbox IdeA
Chantier "permissions des agents" complet bout-en-bout au 2026-06-16, sur la branche `wip/p8c-checkpoint-before-codex`. Lots committes : LP4-0 (`b05d04a`), LP4-1/LP4-2 (`17ca65e`), LP4-3 (`7e01ac6`), LP4-4 (`6236cd7`).
## Acquis (tout vert, ~80 suites)
- **Domaine pur** (`crates/domain/src/permission.rs`, `sandbox.rs`) : modele declaratif (`Capability`, `Effect`, `Posture` Allow<Ask<Deny, deny-wins), `resolve()` (invariant produit : rien pose => `None` => CLI garde son prompting natif), `compile_sandbox_plan(eff, ctx) -> Option<SandboxPlan>`, port `SandboxEnforcer`, `render_permission_summary` (honnetete : fichiers = OS-enforced, commandes = advisory).
- **Store** : `.ideai/permissions.json` (separe d'`agents.json` : securite projet, pas identite).
- **Projection advisory LP3** : projecteurs Claude (`settings.json`) + Codex (sandbox/`config.toml`).
- **Enforcement OS LP4** : `LandlockSandbox` (Linux) / `NoopSandbox` / `default_enforcer()`. Actif sur **les deux chemins** : PTY brut (`pty/mod.rs` `spawn_command_sandboxed`) ET structure Claude/Codex JSON (`session/process.rs` `run_turn_sandboxed`).
## Technique d'enforcement (load-bearing, ne pas casser)
`enforce(plan)` tourne sur un **thread jetable AVANT le spawn**, puis le child est spawne depuis ce thread => il herite le domaine Landlock via les credentials de la tache (garanti par le noyau a travers fork/clone/execve, y compris posix_spawn). **Pas de `pre_exec`** : `infrastructure` est `#![forbid(unsafe_code)]` (intact), et le pre_exec n'aurait ete qu'une assurance de determinisme, sans valeur de securite ; allouer dans `landlock` post-fork (pre_exec) serait au contraire dangereux (deadlock malloc en process multithreade). Fail-closed : `Err` d'enforce => aucun child. Le garde-fou anti-regression est le test e2e **"ecriture hors-grant bloquee"** (present pour PTY et structure) : tant qu'il est vert, l'heritage tient.
## Risque residuel a traiter (signale par l'Architecte, NON couvert)
Les CLI structurees (claude/codex = binaires Node) ont des besoins FS ambiants lourds : `~/.claude`/`~/.codex` (credentials + cache de session pour le **resume**), `node_modules`, libs systeme, caches temp. `compile_sandbox_plan` ne fence que les classes explicitement posees et garde les lectures ouvertes — mais une policy posant un `Deny`/posture restrictive touchant `$HOME` **peut casser le resume**. Le mecanisme est valide au fake CLI (zero token), mais **avant d'activer un plan restrictif en prod sur le chemin structure**, valider e2e manuellement qu'un vrai tour claude/codex sous plan representatif garde run_dir + home de la CLI atteignables. C'est un sujet de **composition du plan** (run_dir reachability ; `SandboxContext.run_dir` existe mais n'est pas encore consomme par la traduction pure), pas du mecanisme — lot suivant si besoin.
Voir [[remaining-work-idea-agent-control-ide]] pour le reste des chantiers produit.

View File

@ -0,0 +1,25 @@
---
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

@ -0,0 +1,37 @@
---
name: rendezvous-600s-cap-too-short-heavy-tasks
description: memory note rendezvous-600s-cap-too-short-heavy-tasks
metadata:
type: project
---
---
name: rendezvous-600s-cap-too-short-heavy-tasks
description: FIX LIVRÉ (2026-06-24) du plafond rendez-vous 600s trop court (T7) — watchdog d'inactivité + extension sur signe de vie + plafond absolu, message distinct cible-active vs no-reply. Built, tests verts, AppImage 09:21 ; validation live T7 en attente.
metadata:
type: project
---
# T7 — plafond rendez-vous trop court : FIX LIVRÉ (2026-06-24)
## Défaut (rappel, observé 2026-06-23)
Délégation dev lourde (impl + `cargo test --workspace` + clippy) → la cible bosse en **un seul long tour > 600 s sans émettre de `turn_duration`**. L'enveloppe serveur `timeout(600s, dispatch)` plate (`crates/infrastructure/src/orchestrator/mcp/server.rs`) expirait sec : (a) faux `-32001`/no-reply **retryable** alors que la cible n'est pas muette mais active ; (b) drop du `dispatch` → canal de report mort → `idea_reply` final non livrable (« no pending request »).
## Fix (branche de travail courante, pas encore committé)
Implémenté par subagent Claude (Architect+DevBackend, hors `idea_ask_agent` car le rendez-vous était le sujet), vérifié par Main (QA réelle), AppImage rebuildée.
- **Algorithme `run_inactivity_watchdog`** dans `server.rs` : `ASK_RENDEZVOUS_TIMEOUT` (600 s, env `IDEA_ASK_RENDEZVOUS_TIMEOUT_MS`) devient une **fenêtre d'inactivité (budget de silence)**, pas un plafond absolu. Boucle `timeout(fenêtre, dispatch)` ; à chaque expiration, sonde l'activité de la cible :
- progrès & sous plafond → réarme (extension) ;
- progrès & plafond atteint → **`rendezvous_ceiling_active_error`** (nouveau code JSON-RPC `error_codes::RENDEZVOUS_CEILING_ACTIVE = -32_002`, `data.code="RENDEZVOUS_CEILING_ACTIVE"`, **`retryable:false`**, message « still actively working… do not retry blindly, check the target's in-progress work/branch ») ;
- pas de progrès (vrai silence, ou **pas de probe = fallback plat**) → `rendezvous_no_reply_error` inchangé (`retryable:true`).
- **Signe de vie = octets cumulés des `.jsonl`** du run-dir cible (couvre le long tour unique sans `turn_duration`). Nouvelle `inspector::claude_paths::transcript_activity_token(fs, home, cwd) -> Option<u64>`.
- **Plafond absolu** `ASK_RENDEZVOUS_CEILING` (défaut **4 h**, env `IDEA_ASK_RENDEZVOUS_CEILING_MS`).
- **Wiring** : sonde optionnelle `AskActivityProbe` injectée dans `McpServer` (modèle `events`/`ready_sink`, additif → zéro régression), branchée par la composition root `crates/app-tauri/src/state.rs` (qui résout nom→AgentId→run-dir via nouveau `service.resolve_agent_id_by_name`). Infra reste libre d'`AgentId`.
- Fichiers : `server.rs`, `jsonrpc.rs`, `mcp/mod.rs`, `lib.rs`, `inspector/claude_paths.rs`+`mod.rs`, `application/.../service.rs`, `app-tauri/state.rs`.
## Validation (preuve réelle, Main)
`cargo test -p infrastructure --lib` = **251 passed/0** (dont 6 nouveaux tests : silence→no-reply, fallback sans probe→no-reply, active→extension puis resolved, active→ceiling, codes/retryable distincts). `mcp_server` 22/0, `inspector_claude` 4/0, `cargo test -p application` tout vert. `clippy -p infrastructure -p application --all-targets` = **0 warning nouveau** (résiduels pré-existants : input/mod.rs, lifecycle.rs, fileguard.rs, server.rs:132 ready_sink). **AppImage rebuildée 2026-06-24 09:21**, installée sur `/home/anthony/Documents/IdeA_0.3.0_amd64.AppImage`, backup `…​.old-pre-t7-fix` (08:41).
## Reste à faire
1. **Validation live T7** après relance IdeA : déléguer une tâche lourde >600 s ; attendu = pas d'expiration tant que la cible écrit son transcript, et soit résolution normale, soit (si >4 h) message ceiling-active non-retryable distinct ; idea_reply tardif non perdu tant qu'on n'a pas atteint le plafond.
2. **Commit par Git** (non fait — laissé à Git, cf. [[git-owns-commit-merge-decisions]]) : décider de le faire avant ou après la validation live T7.
3. Reprise complète des tests **depuis T1** (skill mcp-rendezvous-functional-test). État pré-relance : T1→T6 verts cette passe, dont fix T5 validé live (cf. [[checkpoint-mcp-tests-t1-t5-and-t5-livestate-defect]]).
Lié à [[rendezvous-no-reply-backstop-design]], [[backstop-fires-on-intra-task-turn-rootcause]], [[mcp-functional-test-plan-2026-06-24]].

View File

@ -0,0 +1,14 @@
---
name: rendezvous-no-reply-backstop-design
description: 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).
metadata:
type: reference
---
Le watcher prompt-ready PTY (`infrastructure/src/input/mod.rs` `arm_prompt_watcher`) ne peut PAS servir de signal de fin-de-tour : il est one-shot ré-armé seulement au `bind_handle`, et matche un bandeau TUI **permanent** (`? for shortcuts`) — donc inopérant par tour. Preuve live : aucun `prompt_ready` de toute une session alors que l'agent a travaillé ⇒ c'est le handshake MCP `initialize` (→ `release_agent_cold_start`) qui libère le cold-start, pas le PTY.
**Contrat figé** : `idea_ask_agent` est garanti libéré en temps borné par l'un de :
1. `idea_reply` (chemin propre, renforcé par le préambule comportemental injecté à chaque délégation) ;
2. backstop no-reply sur **stagnation** — transition `Alive→Stalled` (lot-2 `arm_liveness`/`sweep_stalled`) du `Busy{ticket}` ⇒ résolution synthétique « cible silencieuse sans idea_reply » + libération du demandeur ;
3. timeout absolu **fini** (dernier recours) — `ASK_RENDEZVOUS_TIMEOUT` ne doit JAMAIS être 24h ; défaut reco 600 s, env-overridable, garde `Some(0)=no-override`. La borne applicative per-tour (`resolve_turn_timeout`) doit aussi être finie.
Le scraping d'octets ANSI bruts est interdit comme autorité de fin-de-tour (fragile, profil-spécifique). Cold-start = signal MCP `initialize`. Aucun port domaine ni contrat de cartographie n'est touché : tout est infrastructure/application (réutilise lot-2 + sink MCP). Diagnosticabilité : les logs d'armement/bind doivent être en `diag!` (pas `eprintln!`→/dev/null) pour observer armement vs match.

View File

@ -0,0 +1,39 @@
---
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,38 @@
---
name: session-limit-handling-design
description: Design valide pour la detection des limites de session des agents et la reprise auto a la levee.
metadata:
type: project
---
Feature : detecter quand un agent IA est en limite de session (et jusqu'a quelle heure), puis reprendre ou il en etait une fois la limite levee. Cadree le 2026-06-16.
Constat dur : l'heure exacte de reset n'existe nulle part de facon universelle (ni OS, ni code de sortie, ni API inter-modeles) — elle est fabriquee par le fournisseur et seulement exposee dans le flux de sa CLI. Donc « 100% fiable + zero dependance modele + heure exacte » sont incompatibles simultanement ; on vise le meilleur compromis via un detecteur hierarchique.
Solution retenue — detecteur hierarchique calque sur la hierarchie de readiness existante ([[remaining-work-idea-agent-control-ide]]) :
- Niveau 1 (solide) : l'adapter structure extrait limite + reset du flux machine. Pour Claude, `rate_limit_event.rate_limit_info` est DEJA parse dans `infrastructure/session/claude.rs` mais jete (reduit a Heartbeat) — il suffit de lire `resetsAt`.
- Niveau 2 (configurable) : champ de profil `rate_limit_pattern` (regex + capture heure) pour agents PTY/TUI sans adapter structure, dans la lignee des profils declaratifs §9.
- Niveau 3 (filet humain) : si rien ne matche mais agent `Stalled` (deja prevu dans `domain/readiness.rs`), IdeA DEMANDE a l'utilisateur. Garantit le « 100% meme pour un novice » : jamais d'inaction silencieuse.
Model-agnostic tenu AU DOMAINE : le domaine ne connait que `RateLimited { until: Option<Instant> }`. Le savoir specifique modele est confine aux adapters/profils (philosophie §9).
Reprise = partie facile et deja model-agnostique : pivot sur `conversation_id` du moteur + `--resume` natif (deja cable dans `session/claude.rs` + `agent/resume.rs`) qui portent tout l'historique. Pas de reconstruction manuelle fragile.
Decisions produit verrouillees (2026-06-16) :
- Reprise : AUTOMATIQUE a l'heure de reset, ANNULABLE (fenetre + notification).
- Couverture : les TROIS niveaux d'emblee (incl. repli regex niveau 2).
- Etat : EN MEMOIRE uniquement (pas de persistance de SessionLimit). Consequence assumee : le reveil auto ne joue que tant qu'IdeA reste ouvert ; si l'IDE est ferme/rouvert apres le reset, le chemin existant `ListResumableAgents` (agent_was_running/conversation_id) prend le relais.
Decoupage (cycle dev/test §3) : 1) domaine (variante `ReplyEvent::RateLimited`, `ReadinessSignal::RateLimited`, etat `SessionLimit`) ; 2) adapter Claude (extraire resetsAt) ; 3) profil (`rate_limit_pattern`) ; 4) application (planificateur de reprise sur le port Clock) ; 5) UI (badge « limite jusqu'a HH:MM » + filet humain).
Avancement (committe sur `feature/agent-session-limits`) :
- LS1 domaine, LS2 adapter Claude niveau 1, LS3 port Scheduler + TokioScheduler, LS4 service application + reconciliation T4 : DONE.
- LS5 (98bfcf4) detecteur niveau 2 declaratif `RateLimitParser` (regex confinee infra) + module `timeparse` pur partage niveau 1/2 (epoch s/ms, RFC3339, heure murale avec passage de minuit) : DONE, 221 tests infra verts.
- LS6 (ea94e75) cablage : 5 variantes `DomainEvent` (AgentRateLimited/ResumeScheduled/ResumeCancelled/Resumed/RateLimitSuspected) + `ReplyEvent::RateLimited` relayees en `DomainEventDto` (events.rs) ; `chunk_from_event` traite RateLimited -> None (non terminal, comme Heartbeat) : DONE, workspace vert.
- LS7-backend (9df5923) cablage app-tauri : `LaunchAgentOutput.profile` expose (lifecycle.rs), `StructuredSessions::meta_for_session` (registry.rs, lookup N1), `ResumeContext`/`AppAgentResumer` (impl port `AgentResumer` au-dessus de LaunchAgent) + instanciation/drain du `SessionLimitService` (TokioScheduler) dans `AppState::build` (state.rs), taps N1 (agent_send) & N2 (launch_agent, parser regex confine) + commande `cancel_resume` (commands.rs/lib.rs), dep `async-trait`. 2 tests d'integration (session_limit_wiring.rs) verts, suites app-tauri+application vertes. Git : reste sur feature/agent-session-limits, PAS de merge develop avant LS7-front.
- LS7-front (4fad042) : 5 variantes au union `DomainEvent` (src/domain/index.ts) ; etat `limitByAgent` dans useAgents (patron `delegationSourceByRequester`) ; `AgentLimitBadge.tsx` (badge « limite jusqu'a HH:MM » + compte a rebours + bouton « Annuler la reprise » -> port `InputGateway.cancelResume` -> commande `cancel_resume`) ; cable dans AgentsPanel. 24 tests front. Champs wire reels = suffixe Ms : `resetsAtMs`/`fireAtMs` (PAS `resetsAt`/`fireAt`).
- LS8 (filet humain niveau 3, decision Architect = B « demander = armer, pas juste informer ») :
- backend (c480d28) : `SessionLimitService::confirm_human_resume(agent, node, conv, resets_at_ms)` (source `Human`, refactor privé `arm_scheduled` partagé avec `on_rate_limited`, reutilise branche Scheduled, annulable, AUCUN evenement nouveau) ; commande `set_resume_at(agent_id, resets_at_ms)` (resout node_id via `node_for_agent` + conv best-effort, NOT_FOUND si pas de cellule vivante). 15+4 tests (clamp passe, dedup croise, parite auto/humain).
- front (5d9dd32) : `InputGateway.setResumeAt` -> `set_resume_at` ; formulaire de saisie d'heure sur l'etat suspected-sans-heure (helper pur `timeInputToEpochMs`) -> arme la reprise -> badge bascule auto via `agentResumeScheduled`. TODO LS7 retire.
- fix hygiene (3f3504e) : compteur gateways mock 13->14 (`permission`).
- STATUT : FEATURE TERMINEE, 3 niveaux complets, tout vert (Rust domain/application/app-tauri + front agents/adapters 109 tests). MERGEE --no-ff dans `develop` (merge d7041c5, 0 conflit). Branche `feature/agent-session-limits` conservee (non supprimee). Etat = EN MEMOIRE uniquement (pas de persistance SessionLimit, cf. decision verrouillee). Aucun push (develop local en avance sur origin ; action sortante en attente de validation).

View File

@ -0,0 +1,11 @@
---
name: skills-integration-canonical-foundation
description: Topologie d'intégration du chantier skills agent et décision d'abandon de feature/agent-skills.
metadata:
type: project
---
Le chantier « skills agent » : la fondation canonique du domaine skills est **déjà dans `develop`** (introduite par `2332b7f` : port `SkillStore`, `SkillRef` sur `ManifestEntry`, `resolve_skills` dans `LaunchAgent`, CRUD + assign/unassign, **frontend complet** `features/skills/*`).
- `feature/agent-skills` (A, @ef101db) = réimplémentation **obsolète et incompatible** (serde `tag="type"`, `with_updated_content`, pas de `SkillRef`/frontend). **À abandonner** — ne jamais merger, elle régresse develop.
- `feature/agent-skill-awareness` (B, @5be8987) = **surensemble propre** de develop (sa base `8452333` est ancêtre de develop ; diff skill = +539/3). Apporte : `Skill.description`/`effective_description`, manifeste, outil MCP `idea_skill_read` (variante domaine `OrchestratorCommand::ReadSkill`), brief « capacités IdeA » inconditionnel dans `compose_convention_file`.
- Intégration = cherry-pick `ab34363`(+`1a10d67` squash) puis `566bff4` sur develop ; **exclure** `e93a2c1` (cold-start, superseded par `8bb832c`) et le bruit `.ideai/*` (garder seulement `.ideai/memory/feature-agent-skill-awareness-design.md`). Dropper `e93a2c1` évite tout conflit sur `input/mod.rs`. Points chauds : `lifecycle.rs`, `state.rs`.

View File

@ -0,0 +1,64 @@
---
name: ticket14-local-lan-openai-adapter-scoping
description: memory note ticket14-local-lan-openai-adapter-scoping
metadata:
type: project
---
# Ticket #14 — cadrage figé : adapter IA local/LAN OpenAI-compatible canonique
Périmètre figé (review agent-user faite) : canal = **adapter HTTP natif** parlant une API compatible OpenAI/Ollama ; usage **transparent** vs Claude/Codex (mêmes cellules, conversation headless canonique, historique, reprise, délégation, vivacité) ; **PUREMENT ADDITIF** (zéro régression Claude Code / Codex CLI) ; **parité tool-calling/MCP** dès ce ticket avec **dégradation propre** si le modèle n'expose pas les outils.
## 0. Asymétrie structurelle (commande TOUT le design)
| | Claude/Codex (existant) | Modèle local HTTP (#14) |
|---|---|---|
| Nature | binaire CLI spawné | serveur HTTP appelé |
| Boucle agentique | conduite par la CLI | conduite par **IdeA** |
| Rôle MCP d'IdeA | serveur ; CLI = client | pas de client ⇒ IdeA = orchestrateur d'outils |
| Contexte .md | la CLI lit son convention file | injecté en **system message** par l'adapter |
| Conversation | id moteur (session_id/thread_id) | API **stateless** ⇒ transcript possédé par IdeA |
Conséquence : le nouvel adapter **n'utilise PAS** `session/process.rs` (run_turn/spawn/drain). Il ne partage avec claude.rs/codex.rs que les **types de port** (`AgentSession`, `ReplyEvent`). Cette absence de code partagé mutable EST la garantie d'isolation.
## 1. Cartographie hexagonale
**Domaine (crates/domain)**
- Variante `StructuredAdapter::OpenAiCompatible` (profile.rs:244). `provider_key()``"openai-compatible"` (contrat persistance providers.json). Sérialise camelCase `"openAiCompatible"`.
- Nouveau VO validé (parse-don't-validate) `HttpChatConfig { endpoint:String (http/https non vide), model:String (non vide), api_key_env:Option<String> (nom de var env valide, JAMAIS la clé), request_timeout_ms:Option<u32>, connect_timeout_ms:Option<u32>, max_tool_iterations:Option<u16> (garde-fou boucle, défaut ~16) }`. Le domaine ne résout jamais la clé (pas d'I/O env), il porte le **nom** de variable.
- Rattachement `AgentProfile.chat_http: Option<HttpChatConfig>` avec `#[serde(default, skip_serializing_if="Option::is_none")]` (miroir exact de `mcp`/`liveness`/`rate_limit_pattern`, profile.rs:570-604) ⇒ **zéro régression de sérialisation** (profils Claude/Codex bit-identiques). Test round-trip obligatoire (miroir profile_without_mcp_round_trips_identically).
**Nouveau port tool-calling (le seam clé — le pont MCP .mcp.json/config.toml + bridge `idea mcp-server` NE s'applique pas, pas de client CLI)**
```rust
pub struct ToolSpec { name:String, description:String, input_schema:serde_json::Value }
#[async_trait] pub trait ToolInvoker: Send+Sync {
fn tools(&self) -> Vec<ToolSpec>;
async fn call(&self, name:&str, args_json:&str) -> Result<String, ToolInvocationError>;
}
```
Implémenté en **app-tauri** en déléguant à la **même** `OrchestratorService::dispatch` (orchestrator/service.rs:1082) que le endpoint MCP ⇒ parité délégation/rendez-vous (idea_ask_agent/idea_reply), gating permissions/sandbox conservé. Injecté dans la factory via `with_tool_invoker(Arc<dyn ToolInvoker>)` (jumeau de `with_sandbox_enforcer`). `None` ⇒ tool-calling désactivé proprement (chat nu).
**Infra** : nouveau fichier `crates/infrastructure/src/session/openai_compat.rs` (jumeau structurel de codex.rs SANS process). Client HTTP **reqwest + rustls-tls** (jamais native-tls — spike AppImage §13-2, confiné au crate infra). Parsing isolé pur `parse_chat_delta`/`parse_completion` (miroir de parse_event) — seul endroit qui connaît le schéma OpenAI (choices[].message, tool_calls[], SSE data:).
**Routing — seul contact avec l'existant** : `StructuredSessionFactory::start` (factory.rs:111) = **UN bras de match ajouté** ; bras Claude/Codex INTOUCHÉS ; `supports()` reste `profile.is_selectable()` (=structured_adapter.is_some(), profile.rs:857) ⇒ sélectionnable sans changer le prédicat.
## 2. Contrat de session headless
`send(prompt)` : 1) transcript.push(user) ; 2) émettre Heartbeat ; 3) POST {endpoint}/chat/completions {model, messages:transcript, tools?:invoker.tools(), stream:true} ; 4) si tool_calls ⇒ pour chaque: ToolActivity{label=name} + result=invoker.call(name,args) + push(assistant tool_call)+push(tool result), reboucler (borné max_tool_iterations) ; 5) sinon streamer chunks ⇒ TextDelta (+tap→Announcement, cf claude.rs:337) ; 6) réponse complète ⇒ push(assistant) + **Final{content}** ; 7) persister transcript run dir. Contrat de flux universel respecté (un seul Final terminal) ⇒ send_blocking/drain_with_readiness marchent tels quels.
**Erreurs (jamais de corps HTTP brut propagé)** : endpoint injoignable 1er contact/probe ⇒ `AgentSessionError::Start` (UI erreur, IdeA non bloqué) ; réseau/coupure en tour ⇒ `Io` ; JSON illisible/schéma ⇒ `Decode` (diagnostic court) ; timeout ⇒ `Timeout` via send_blocking, session non tuée ; modèle absent (404/400) ⇒ `Start` dédié.
**Reprise sans mélange d'ids (invariant du ticket)** : /chat/completions **stateless** ⇒ AUCUN id provider ⇒ `conversation_id()` retourne **None** (rien à mélanger). État = transcript provider-shaped (roles+tool_calls) **possédé par IdeA**, persisté dans le **run dir stable** `.ideai/run/<agent-id>/chat-transcript.json` (clé = agent, jamais id provider). Reprise = ré-instanciation factory ⇒ rechargement transcript ; `seed_conversation_id` (factory.rs:63) **ignoré** par cet adapter (documenter). DISTINCT du conversation-log LS6 (log.jsonl, dérivé ReplyEvent, surface humaine, inchangé) — deux artefacts, aucun mélange.
**Contexte** : `start` reçoit `ctx:&PreparedContext` ; `ctx.content` (ports.rs:120) = Markdown rendu ⇒ injecté comme premier message **system** (le serveur HTTP ne lit pas de convention file).
## 3. Seam tool-calling / dégradation
Parité : ToolInvoker câblé ⇒ modèle local voit idea_* via la même OrchestratorService (délégation/rendez-vous/contexte/mémoire/tickets identiques, gating conservé). Dégradation 3 niveaux : (1) ToolInvoker None ⇒ chat nu ; (2) profil opte sans outils ⇒ idem ; (3) endpoint rejette param `tools` ⇒ détecter, retirer tools, rejouer chat nu, 1 diagnostic — l'agent converse toujours, sans déléguer. Garde-fou max_tool_iterations (modèles locaux moins fiables) ⇒ au plafond, Final + note.
## 4. Lots B/F
Backend : **B1** domaine (variante+provider_key, VO HttpChatConfig, champ chat_http, port ToolInvoker/ToolSpec/ToolInvocationError ; tests sérialisation zéro-régression, round-trip, invariants ; zéro I/O). **B2** adapter infra openai_compat (reqwest/rustls, parse_* purs, mapping ReplyEvent+erreurs, résolution clé env ; tests fixtures OpenAI/Ollama, erreurs via wiremock, pas de fuite payload). **B3** boucle outils bornée + persistance/rechargement transcript run-dir (reprise) + dégradation tools non supporté (tests ToolInvoker fake, reprise=rechargement, plafond). **B4** routing (bras match) + composition root (with_tool_invoker, impl ToolInvoker→OrchestratorService) + profil de référence "Ollama / OpenAI-compatible local model" éditable (tests factory route, supports true, probe indispo→Start).
Frontend : **F1** types TS HttpChatConfig + champ chatHttp? + adapter "openAiCompatible". **F2** wizard/settings : sélectionnable comme Claude/Codex, form endpoint/model/apiKeyEnv/timeouts, validation miroir backend (first-run/profile.ts isValidEnvVar, URL, non-vide), apiKeyEnv = nom de var jamais clé. **F3** cellule = chemin chat structuré existant (dérivé de is_selectable, "gratuit" si DTO respecté) + erreur "endpoint indisponible" propre sans bloquer UI (tests RTL gateways mock).
Frontière B↔F : **DTO AgentProfile** (déjà le pont IPC) porte structuredAdapter:"openAiCompatible" + chatHttp{endpoint,model,apiKeyEnv?,requestTimeoutMs?,connectTimeoutMs?,maxToolIterations?}. Sélectionnabilité + rendu chat dérivés du DTO existant, pas de nouveau canal ni commande Tauri au cœur (le seed du profil de référence peut passer par le CRUD profils existant — à confirmer B4/F3).
## 5. Vigilance régression / invariants
1. Zéro régression sérialisation (skip_serializing_if=Option::is_none ; round-trip Claude/Codex bit-identique — BLOQUANT). 2. Isolation code : nouvel adapter = fichier neuf ; INTERDIT de toucher claude.rs/codex.rs/process.rs ; seul diff existant = 1 bras match factory.rs + champs optionnels domaine. 3. Contrat flux : exactement un Final terminal ; Heartbeat/ToolActivity/TextDelta/RateLimited non terminaux (conformance.rs doit couvrir le nouvel adapter). 4. Frontière domaine : reqwest UNIQUEMENT infra ; aucun type HTTP en domaine/application ; ToolInvoker port pur. 5. Nouvelle dépendance AppImage : reqwest rustls-tls (pas OpenSSL, spike §13-2). 6. Non-mélange ids : conversation_id()=None ; transcript clé-agent ; distinct de LS6. 7. Sandbox : pas de process spawné ⇒ SandboxEnforcer OS = no-op pour le tour (pas une régression) mais les outils via ToolInvoker gardent le gating orchestrateur.
## 6. Décisions produit remontées à Main (NON tranchées par Architect)
1. Surface d'outils v1 : parité totale immédiate vs sous-ensemble curaté (fiabilité tool-calling des modèles locaux). Reco : parité + garde-fou max_tool_iterations.
2. Streaming SSE dès v1 (reco, parité observabilité live) vs non-streaming (repli si endpoint ne stream pas).
3. Nom canonique variante : `OpenAiCompatible` (reco, décrit le protocole ; provider_key figé) vs `LocalChat` (formulation ticket).

View File

@ -0,0 +1,29 @@
---
name: ticket16-menus-floating-delivered-devfrontend
description: memory note ticket16-menus-floating-delivered-devfrontend
metadata:
type: project
---
# Lot A / #16 — MenuBar + FloatingWindow livré (DevFrontend)
Branche `feature/ui-menus-floating` (base develop 0218e32), non commité, avant merge Git. `vitest` **vert** : 54 fichiers / 527 tests. `tsc --noEmit` exit 0.
## UX pass validée utilisateur (barre unique + sélecteur projet) — APPLIQUÉE
- **Barre unique** : plus de MenuBar séparée dans App.tsx. Une seule MenuBar dans `ProjectsView` regroupant `[ Projet: <actif> ▾ ] File ▾ View ▾ Settings ▾`.
- **Sélecteur de projet permanent** : premier menu de la barre, label = projet actif, items = tous les projets connus (`vm.projects`) → `selectProject(id)` (active l'onglet si ouvert, sinon `openProject`). Accessible même sous projet actif, sans ouvrir File→Projects….
- **Settings → AI Profiles** déplacé dans la barre unique : toggle `showSettings` LOCAL à ProjectsView ; le main area swap vers `<ProfilesSettings/>` pendant que la barre reste visible (permet de refermer). App.tsx ne gère plus showSettings ni ProfilesSettings (juste firstRun ? wizard : ProjectsView).
## Fichiers (état final)
- **Créés (lot A initial)** : `shared/ui/FloatingWindow.tsx`, `shared/ui/MenuBar.tsx`, `shared/ui/FloatingWindow.test.tsx`.
- **Modifiés** : `shared/index.ts`, `shared/ui/zIndex.ts` (réutilisé), `app/App.tsx` (barre + showSettings + ProfilesSettings retirés), `features/projects/ProjectsView.tsx` (barre unique : projectMenu+File+View+Settings, showSettings local, ProfilesSettings dans main), `features/projects/projects.test.tsx` (+2 tests : sélecteur projet, toggle AI Profiles), `features/projects/ProjectsView.ls7.test.tsx`.
## Invariants conservés
- FloatingWindow (focus-trap+Échap+backdrop, z=floatingWindow 50), MenuBar dropdowns z=menuDropdown 40, toasts z=toast 70, zIndex canonique réutilisé.
- TOUS les panneaux atteignables via **View** (context, work, tickets, agents, templates, skills, perms, memory, git) + File→Projects…. Critère d'acceptation respecté.
- Non touché : `shouldShowWritePortalVeil`, exclusion write-portal↔F3, overlays in-cell, TicketPicker (#18).
## Notes
- ProfilesSettings rendu DANS le main de ProjectsView (barre + onglets projet restent visibles au-dessus) au lieu du swap plein-écran App précédent — meilleure continuité, barre unique toujours accessible.
- Pas de run live Tauri (couverture RTL mock-driven). DoD vitest satisfaite.
QA/utilisateur revalident avant merge Git.

View File

@ -0,0 +1,9 @@
---
name: ticket17-focus-trap-fix-merged-develop
description: Correctif de la perte de focus dans l'édition de ticket (#17) livré sur develop via feature branch dédiée.
metadata:
type: reference
---
Bug #17 : saisie une lettre à la fois dans le formulaire d'édition de ticket, cause = focus-trap `FloatingWindow` avec `useEffect` dépendant de `[onClose]` (closure recréée à chaque render). Fix DevFrontend : `onCloseRef` + effet focus-trap mount-only (`[]`).
Topologie Git : branche `feature/ticket17-focus-trap-fix` depuis `develop`, commit `4cccd40` (2 fichiers frontend seulement), merge `--no-ff``develop` = `2f8467e`, branche supprimée. Vert : tsc clean, 531/531 + test de régression. Voir [[ticket16-menus-floating-delivered-devfrontend]], [[ui-rework-sprint-scoping-contracts]].

View File

@ -0,0 +1,28 @@
---
name: ticket18-picker-delivered-devfrontend
description: memory note ticket18-picker-delivered-devfrontend
metadata:
type: project
---
# Lot B / #18 — TicketPicker livré (DevFrontend)
Branche `feature/ticket-picker-popup` (base develop d97abb1). `vitest` **vert** : 53 fichiers / 515 tests, dont 8 nouveaux (`TicketPicker.test.tsx`) + 29 `tickets.test.tsx` inchangés (valide la non-régression du listing après extraction). `tsc --noEmit` clean.
## Fichiers
- **Créés** : `shared/ui/zIndex.ts`, `features/tickets/TicketFacetsBar.tsx`, `features/tickets/useTicketSearch.ts`, `features/tickets/TicketPicker.tsx`, `features/tickets/TicketPicker.test.tsx`.
- **Modifiés** : `shared/index.ts` (export zIndex), `features/tickets/index.ts` (barrel), `features/tickets/TicketsPanel.tsx` (consomme `TicketFacetsBar`).
## Écarts de contrat à trancher (signalés à Main)
1. **Emplacement TicketPicker** : placé sous `features/tickets/`, PAS `shared/ui`, car il dépend du domaine ticket + gateways DI (shared/ui = design system pur). Conforme à tous les autres overlays (SprintManager, MemoryEditor…). Seul `zIndex.ts` (niveau design-system) est dans shared/ui.
2. **`TicketPickerResult.id`/`number`** : `ticket_list`/`TicketSummary` ne portent NI `id` NI `number`. Résolus par un `ticket_read` unique **à la sélection** (`useTicketSearch.resolve`). `number` serait dérivable du ref mais `id` exige la lecture. → contrat `{ref,id,number,title,status,priority}` respecté sans nouveau endpoint. Écart backend candidat : ajouter id/number au summary (dette basse).
3. **`zIndex.ts` provisoire** : lot A (#16) introduit le canonique en parallèle. Valeurs alignées sur l'échelle figée (menuDropdown=40, floatingWindow=50, floatingWindowNested=60, toast=70). **À réconcilier au merge** (garder un seul module). Picker monté à `floatingWindowNested=60`.
## Notes d'impl
- G3-bis respecté : `cursor` traité en token opaque (jamais construit/incrémenté ; relayé verbatim via `loadMore`).
- `excludeRefs` filtré client-side après réception de page.
- `useTicketSearch` léger (pas de groupement sprint, pas de souscription events, debounce 200ms) — ne réutilise pas `useTickets`.
- `TicketFacetsBar` = recherche + facettes statut/priorité (labels aria préservés : `search tickets`, `filter status …`, `filter priority …`, `clear filters`). Le select assignee reste dans `TicketsPanel` (hors périmètre picker).
- Focus-trap inline (Tab cycling + Escape + restore focus) car aucun util partagé n'existe ; G5 respecté (montage niveau chrome par le consommateur #17/#19).
- `selectionMode:"multi"` câblé de façon extensible (footer réservé) mais non actif en V1.
QA repasse derrière. Consommateurs #17 (link) et #19 (sprint) importent `TicketPicker` depuis `@/features/tickets`.

View File

@ -0,0 +1,11 @@
---
name: ticket25-assistant-sandbox-eacces-rootcause
description: Root cause et contrat de fix du EACCES (os error 13) au spawn de la CLI d'un assistant de ticket — le preset SandboxPlan::project_read_only handle la classe exec Landlock.
metadata:
type: reference
---
**Symptôme** : ouvrir un assistant de ticket (Codex ou Claude), premier message ⇒ `process error: agent session start failed: <cli>: Permission non accordée (os error 13)`. Indépendant de la CLI.
**Root cause** : `OpenTicketAssistant::execute` (`application/src/ticket_assistant.rs:97`) fabrique un plan bespoke via `SandboxPlan::project_read_only` (`domain/src/sandbox.rs:153`) = grant **RO** sur `project_root` + RW sur le run_dir, posture `Deny`. Dans l'adapter Landlock (`infrastructure/src/sandbox/landlock.rs:70`), un grant RO *handle* la classe read, et `AccessFs::from_read(V1)` **inclut `AccessFs::Execute`**. Le binaire CLI vit hors du project root ⇒ `execve` refusé ⇒ EACCES au `spawn()` sandboxé (`process.rs:248`). Le chemin workspace n'a pas le bug car son plan vient de `compile_sandbox_plan` sous posture `Allow`/write-only ⇒ l'adapter no-op ou ne handle que write, read/exec restent ouverts. Piège déjà documenté dans l'adapter (« enrichment is the launch-path's concern LP4-2 »).
**Fix (backend-pur, zéro port/DTO)** : remplacer le preset par un **write-fence** — ne jamais handle read/exec (pas de grant RO), handle write seul, RW-grant = run_dir + state/home CLI + temp, posture Deny ⇒ écriture projet refusée, binaire/libs/home lisibles-exécutables. Fallback sûr : passer `None` à `factory.start` pour la surface ticket (garde policy MCP + projection advisory). Garde-fous fonctionnels réels = policy MCP `idea_ticket_read/update*` + LP3, pas l'OS-sandbox. Lié à [[ui-rework-sprint-scoping-contracts]].

View File

@ -0,0 +1,17 @@
---
name: ticket28-f1-frontend-delivered
description: Lot F1 du ticket #28 livré sur feature/ticket28-firstrun-detect-hang — invariant busy/detectProfiles, flag detecting, timeout UI, test de non-régression.
metadata:
type: reference
---
Lot **F1** (frontend) du bug #28 implémenté sur `feature/ticket28-firstrun-detect-hang` (non committé, Git s'en charge).
**Invariant posé** : dans `frontend/src/features/first-run/useFirstRun.ts`, le retour de `busy` à `false` ne dépend d'aucun appel à `detectProfiles`. `busy` n'entoure plus que `firstRunState()` (reload) et `configureProfiles()` (finish). Toute future régression qui remet un `await profile.detectProfiles(...)` sur un chemin gouvernant `busy` re-gèle le wizard.
**Mécanisme** : `runDetection(candidates, { preselect, reportError })` factorise auto-détection et bouton manuel. Le flag `detecting` est relâché par un `setTimeout(DETECT_TIMEOUT_MS = 3_000)`, **jamais** par la promesse — car le `finally` d'un `await` sur une promesse jamais settled (panic Rust ⇒ pas de réponse IPC) n'est jamais atteint. Un compteur `detectRun` invalide les rounds périmés (re-clic, unmount).
**Piège UI à retenir** : `<Button loading>` implique `disabled` dans le design system (`shared/ui/Button.tsx:46`). Donc `detecting` ne peut pas être surfacé via `loading` sur les boutons Save/Detect sans réintroduire le grisage — il est rendu comme un `role="status"` « Detecting… » séparé.
**Point de vérité QA** : `FirstRunWizard.test.tsx`, describe « detection that never answers (ticket #28) », gateway `HangingDetectGateway` dont `detectProfiles` renvoie `new Promise(() => {})`. Vérifié à teeth : en réintroduisant `setBusy(true); await runDetection(...)` dans `reload`, 2 des 3 tests échouent avec exactement le symptôme du ticket.
Vert : `npx vitest run` 59 fichiers / 569 tests, `npx tsc --noEmit` exit 0. Pas de lint dans ce projet (aucun eslint config ni script). F1 débloque l'UI mais **B1 (DevBackend, `AgentRuntime::detect` sync→async) reste requis** pour que la détection remonte réellement un résultat.

View File

@ -0,0 +1,19 @@
---
name: ticket28-firstrun-detect-hang-scoping
description: Cadrage hexagonal du bug bloquant first-run (#28) — panic block_on imbriqué dans detect + découplage busy/détection, contrats et point de vérité QA.
metadata:
type: reference
---
Bug high #28 (build 0.3.0 / develop 3c6cd04) : au first-run, « Save and continue » ET « Detect installed CLIs » restent grisés → wizard impossible à terminer.
**Cause racine unique (bloquante) — CONFIRMÉE source :** `AgentRuntime::detect` est resté `fn` synchrone (`domain/src/ports.rs:754`, impl `infrastructure/src/runtime/mod.rs:182`) alors que le trait est déjà `#[async_trait]`. L'impl bridge le spawner async via `futures_block_on`/`block_on` (mod.rs:228-237), appelé DANS la commande async Tauri `detect_profiles``DetectProfiles::execute` (async) → `detect()` sync sur la même task → tokio panic « Cannot start a runtime from within a runtime ». Un panic dans une commande async Tauri = **aucune réponse IPC** → promesse `invoke` jamais résolue/rejetée → le try/catch interne (`useFirstRun.ts:79-90`, n'attrape que les rejets) ne l'attrape pas → `finally` jamais atteint → `busy` figé true → boutons `disabled: vm.busy` grisés à vie. Se déclenche au 1er profil sondé, toute machine. Déclencheur nouveau de #14 : auto-détection à l'ouverture dans `reload`.
**Cause secondaire (NON bloquante) :** profil `ollama-openai-compatible` (command `openai-compatible`, `detect:None`) → fallback `openai-compatible --version` (binaire absent) → `available:false` erroné (spawn échoue vite, pas de hang). Endpoint HTTP sondé comme un CLI = catégorie-fausse. base_url dispo via `HttpChatConfig` (http://localhost:11434/v1). Précédent réutilisable : `infrastructure/src/store/embedder.rs:401 detect_ollama` (reqwest, timeout 800ms, feature vector-http).
**Fix figé — Backend (DevBackend) :** B1 promouvoir `detect` en `async fn` (supprimer futures_block_on entièrement), maj `DetectProfiles::execute` (.await) + commande. B2 `tokio::time::timeout` borné par probe. B3 brancher endpoint-kind (chat_http / StructuredAdapter::OpenAiCompatible) → probe HTTP best-effort borné de base_url (jamais d'erreur dure) ; CLI-kind = `detection_spec` INCHANGÉ (zéro-régression Claude/Codex). Aucun nouveau port/adapter.
**Fix figé — Frontend (DevFrontend) :** F1 découpler `busy` de la détection : `busy` n'entoure que `firstRunState()`, relâché dès rendu des lignes. Auto-détection = étape détachée non bloquante suivie par un flag distinct `detecting` (ne grise pas Save), avec timeout UI (~3s). Invariant : retour de busy à false ne dépend JAMAIS de detectProfiles.
**Contrats :** port `AgentRuntime::detect` sync→async (validé Architecture). DTO detect_profiles INCHANGÉ (available:bool). Catalogue ollama : detect reste None, détection décidée par nature endpoint.
**Point de vérité QA :** Backend = test `#[tokio::test]` multi-thread sur DetectProfiles::execute (échoue au panic sur code actuel, passe après B1) + endpoint sans spawn CLI + CLI Claude/Codex inchangé. Frontend = RTL avec mock detectProfiles jamais résolu → Save+Detect actifs dès firstRunState. Live = first-run machine sans Claude/Codex, Ollama coché, boutons actifs, Save termine (rebuild AppImage obligatoire). F1 seul débloque déjà ; B1 supprime la cause racine ; les deux requis pour vert.

View File

@ -0,0 +1,18 @@
---
name: ticket4-announcements-frontend-f1f2f3
description: Topologie du frontend des annonces inter-agent (store borné, preview demandeur filtré requester, overlay cible piloté par le busy/idle par agent) — réintégré sur base develop.
metadata:
type: project
---
Branche `feature/agent-live-announcements` (base develop `ebd992e`, non commité). Frontend réintégré depuis `backup/announcements-work-20260704`. Feature `frontend/src/features/announcements/` :
- `announcementsStore.ts` : index pur `byTarget[target][ticketId]->Announcement[]`, `appendAnnouncement` borné (cap 50), `purgeAllForTarget` (au busy:false), sélecteurs target/requester. Éphémère, jamais persisté. (`purgeTurn` du backup RETIRÉ — plus de signal final sur develop.)
- `AnnouncementsProvider.tsx` (monté dans App.tsx) : 1 abonnement `system.onDomainEvent`. Deux signaux : CONTENU = `agentAnnouncement`→append ; CYCLE DE VIE = map `busy` par agent, seule autorité de montage/retrait, alimentée par `agentBusyChanged{agentId,busy}` + hydratée du read-model `ProjectWorkState.agents[].busy` via `useHydrateAgentBusy(projectId,agentId)` (seed « si absent » → event live gagne). `busy:false`→purgeAllForTarget. Hooks `useTargetAnnouncements` (active=busy[target]), `useRequesterAnnouncements`, `useHydrateAgentBusy`. Hors provider = store inerte.
- F3 `TargetAnnouncementsOverlay(projectId,agentId)` monté dans **`LayoutGrid` LeafView** (PAS ConversationCell — absent sur develop ; la cellule agent est le PTY `TerminalView`). Overlay `pointer-events-none`, z-20, au-dessus du write-portal overlay existant. F2 `AnnouncementsPreview` par ligne d'`AgentsPanel` (requester==a.id).
ADAPTATION develop appliquée : `agentTurnEvent{final}` N'EXISTE PAS sur develop → branche de purge retirée du provider, type NON réintroduit dans domain, 2 tests agentTurnEvent supprimés. Autorité unique F3 = busy. Confirmé présents sur develop : `agentBusyChanged{agentId,busy}` (domain/index.ts) et `AgentWorkState.busy: {state:"idle"}|{state:"busy";ticket;sinceMs}`. DTO annonce backend confirmé (events.rs, test JSON à events.rs:927) : `{type:"agentAnnouncement",projectId,requester("user"|agentId),target,ticketId,text,atMs}` — mirroir ajouté dans domain/index.ts.
Exclusion des voiles (arbitrage [[ticket4-overlay-composition-leafview]]) : le voile write-portal (injection PTY) et l'overlay F3 partagent le conteneur relatif du LeafView. Prédicat pur exporté `shouldShowWritePortalVeil(agentPinned, writePortalOverlay, busyActive) = agentPinned && overlay && !busyActive` ; F3 se gate sur le même `busyActive` (`useTargetAnnouncements(agentId).active`, remonté au LeafView). Résultat : exactement UN voile, F3 prioritaire. Purement visuel — `portal.isSuspended()`/l'injection PTY (TerminalView) INCHANGÉS. Testé exhaustivement (table de vérité) dans `overlayExclusion.test.ts`.
Écarts tranchés à signaler : (1) F3 hébergé dans la cellule PTY (LeafView) faute de ConversationCell ; (2) busy est l'autorité brute : sur develop busy vient du mediator (délégations/inter-agent), pas du typing PTF humain, donc proxy correct, mais surveiller un éventuel over-trigger ; (3) F2 filtre requester seul (pas de ticketId par ligne) = garde anti-fuite.
Build vert, 51 fichiers / 481 tests vitest verts.

View File

@ -0,0 +1,25 @@
---
name: ticket4-overlay-composition-leafview
description: Règle de composition des deux voiles plein-cellule de LeafView (write-portal injection PTY vs F3 annonces busy) — exclusion mutuelle avec priorité F3, arbitrée pour éviter le double voile.
metadata:
type: reference
---
Arbitrage layout Architect 2026-07-04 (branche feature/agent-live-announcements, base develop ebd992e, 481 tests verts).
**Problème vérifié :** LeafView héberge DEUX voiles plein-cellule inset:0 dans le même conteneur relatif :
- write-portal (LayoutGrid.tsx:841, zIndex:4, rgba(0,0,0,0.45), « Un agent est en train de parler… ») = délégation injectée dans le PTY de l'agent (§20.3, flag `overlay` de useWritePortal).
- F3 TargetAnnouncementsOverlay (z-20, bg-canvas/85, « …en train de LUI parler… » + réflexions) = agent busy (agentBusyChanged mediator).
Ils rendent le MÊME événement depuis deux signaux et montent ENSEMBLE sur le chemin d'injection inter-agent (overlay+busy) → double voile empilé + bannières dupliquées = rendu cassé, chemin nominal.
**Décision (DevFrontend, layout, zéro backend) :** exclusion mutuelle, un seul voile à la fois, priorité F3 :
- busy(agent) → F3 seul ; voile write-portal gated `agentId!=null && overlay && !busyActive`.
- sinon overlay → write-portal seul (repli fenêtre sans busy).
- jamais les deux.
Sécurité : on ne touche que le visuel ; la suspension des frappes (portal.isSuspended(), TerminalView.tsx:182) reste ; F3 est pointer-events-none.
**Couplage point 3 :** F3 DOIT rendre la bannière sur busy même à 0 annonce (déjà: if(!active) return null, TargetAnnouncementsOverlay.tsx:56), car F3 absorbe le voile write-portal — une garde « ≥1 annonce » rouvrirait le trou d'indication. Pas de garde.
**F2 (point 4) :** filtre requester==id de ligne suffit en V1 (isolation fil partagé) ; ticketId optionnel dormant.
**F3 hébergement (point 1) :** conteneur LeafView validé (pas de ConversationCell sur develop).
Liens : [[ticket4-restart-on-develop-ebd992e]], [[ticket4-f3-overlay-driven-by-agentbusychanged]], [[inter-agent-live-context-shared-per-agent]].

View File

@ -0,0 +1,20 @@
---
name: ticket4-restart-on-develop-ebd992e
description: 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.
metadata:
type: reference
---
Redémarrage #4 sur base réalignée main=develop=feature/background=feature/agent-live-announcements=ebd992e (pré-canonique). Vérifié sur le dépôt le 2026-07-04.
**Signaux sur develop :**
- Émission intermédiaire : AUCUNE. codex.rs draine via run_turn BATCH (process.rs:268/321 lit ligne-à-ligne mais collecte en Vec, renvoie à EOF ; codex.rs:260 Box::new(events.into_iter())). structured.rs:266-271 jette TextDelta/ToolActivity/Heartbeat, ne renvoie que Final.
- Busy PAR AGENT : PRÉSENT ET COMPLET. DomainEvent::AgentBusyChanged{agent_id,busy} (domain/events.rs:171), autorité mediator (infrastructure/input/mod.rs:433), relay (app-tauri/events.rs:484), front event domain/index.ts:22 + read-model agents[].busy {state,ticket,sinceMs} (:220,304) réconcilié reboot. ⇒ autorité overlay F3 dispo telle quelle.
- Fix Final : PRÉSENT (62915ee) mais dégrade les agent_message intermédiaires en ToolActivity{label} en JETANT leur texte, et reste batch → inexploitable pour annonces.
**Écart live (faisable SANS moteur canonique) :** run_turn lit déjà incrémentalement ; le batch n'est qu'un artefact de sa signature ->Vec. Ajouter un tap Option<mpsc::Sender<String>> dans run_turn/drain/drain_sandboxed (boucle existante) ; l'orchestrateur (qui détient requester/target/ticket) publie DomainEvent::AgentAnnouncement au fil de l'eau. Thread Landlock n'envoie que des lignes brutes ; publication bus hors thread. Pas de spawn_turn/AgentTurnEvent/ConversationId.
**Réutilisabilité backup (backup/announcements-work-20260704, 691b2ce) :** frontend features/announcements/ (store borné, provider, AnnouncementsPreview=F2, TargetAnnouncementsOverlay=F3) réutilisable ; F3 sur busy = intact sur develop. Dépend d'agentAnnouncement{requester,target,ticketId,text,atMs} (absent→B) et agentTurnEvent{final} (absent, secondaire → RETIRER du store). Backend backup non réutilisable (canonique) ; contrat/attribution repris.
**Découpage :** B1 domaine/appli (ReplyEvent::Announcement + DomainEvent::AgentAnnouncement + publish au drain) ; B2 infra = CŒUR (tap mpsc process.rs + codex émet Announcement{text} live) ; B3 relay/DTO ; F1 store (hook final) ; F2 preview (filtre ticketId+requester==self) ; F3 overlay (réutilisé, busy seul autorité).
Liens : [[ticket4-f3-overlay-driven-by-agentbusychanged]], [[ticket4-announcements-reintegration-topology]], [[inter-agent-announcements-feature-and-codex-final-bug]], [[inter-agent-live-context-shared-per-agent]].

View File

@ -0,0 +1,16 @@
---
name: ticket7-f2-delegated-limit-no-agentratelimited
description: Écart backend ticket #7/F2 — le rendez-vous délégué n'émet pas AgentRateLimited ni n'arme la reprise pour la cible limitée.
metadata:
type: project
---
Ticket #7, volet inter-agent. Constat F2 (frontend DevFrontend) sur `feature/session-limit-interagent`.
Le chemin délégué (rendez-vous headless) **n'appelle jamais** `session_limit_service.on_rate_limited(target, …)`. Dans `crates/application/src/orchestrator/service.rs:1876-1915`, la branche `TargetRateLimited` publie **uniquement** `DomainEvent::DelegationRateLimited{requester, target, resets_at_ms}` puis retourne `AppError::TargetRateLimited`. Les deux seuls sites de `on_rate_limited` sont les chemins humains PTY/chat (`crates/app-tauri/src/commands.rs:1409` et `:1535`).
**Conséquence** : quand la cible B est limitée **via une délégation**, aucun `AgentRateLimited`/`AgentResumeScheduled` n'est émis pour B ⇒ le badge mono-agent de B (piloté par `limitByAgent` dans `useAgents`) ne s'affiche pas et aucune reprise auto n'est armée pour B. Contredit le commentaire de `crates/app-tauri/src/events.rs:370-372` (« the target resume flow is surfaced by the existing agent limit events »).
**Why:** F2 supposait « même flux AgentRateLimited ». Le rendu frontend du badge est sain (re-render + bouton Annuler OK) ; l'écart est backend.
**How to apply:** correction = backend (appeler `on_rate_limited` pour la cible dans la branche rendez-vous, avec node/conversation adéquats). Ne PAS dériver le badge de B depuis `delegationRateLimited` côté front : cet event ne porte ni sémantique de reprise armée ni node_id/conversation_id pour armer le réveil → inventerait un contrat. Le côté DEMANDEUR (A) est, lui, bien couvert par F1 (`suspendedDelegationsByRequester`). Voir [[session-limit-handling-design]].

View File

@ -0,0 +1,15 @@
---
name: tickets-frontend-v1-done
description: État du frontend du système de tickets — livré, vert, décisions de contrat clés.
metadata:
type: project
---
Frontend V1 du système de tickets livré sur `feature/issue-ticket-system` (non commité, attend QA/Git). Build + 459 tests verts.
Décisions figées :
- Port nommé `TicketGateway` (pas IssueGateway) — aligné sur le wire `ticket_*`/`TicketDto` et le terme visible « ticket ».
- Statut/priorité côté UI passent par `ticket_update` : `ticket_update_status`/`ticket_update_priority` ne sont PAS des commands Tauri (MCP-only, non enregistrées dans `lib.rs`).
- Conflit de version = `code:"INVALID"` + message contenant `"issue version conflict"` (détection par message, pas de code dédié). Voir `isTicketVersionConflict`.
- F7 = `#ref` cliquables + linkification desc + bouton clipboard « Travaille sur le ticket #N : <titre> » (pas d'écriture terminal directe en V1).
Surface : `features/tickets/` (panel liste + overlay détail/carnet/liens/assign), onglet sidebar « Tickets » dans ProjectsView entre Work et Agents, `MockTicketGateway` émet les events `Issue*`. Voir [[checkpoint-issue-ticket-backend-v1-done]] et [[issue-ticket-system-design]].

View File

@ -0,0 +1,15 @@
---
name: tickets-t3-frontend-validation-verdict
description: 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.
metadata:
type: reference
---
Validation frontend du fix T3 (ticket #1), branche `feature/background-tasks-first-class`, 2026-07-03.
**Verdict : vert.** `npx vitest run` = 460/460, `npm run build` (tsc --noEmit + vite) OK. Le front était déjà câblé pour Cancel/Retry ; contre le vrai payload backend le mapping d'états et l'activation des boutons fonctionnent.
**Contrat backend réel** (`crates/app-tauri/src/dto.rs::AgentBackgroundTaskStateDto`, camelCase) : `taskId, kind, state, exitCode?, summary?, stdoutTail?, stderrTail?, createdAtMs, updatedAtMs`. `state` ∈ queued|running|waiting|completed|failed|cancelled|expired ; `kind` ∈ command|headlessRendezvous|sessionResume|maintenance. **Pas** de `status`, `ownerAgentId`, `projectId`, ni `finishedAtMs`.
**Fait :** FE-1 rendu explicite `queued`/`waiting``pending` dans `normalizeBackgroundStatus`. FE-2 ajout d'un test sur le vrai shape dans `src/features/workstate/workstate.test.tsx` (le mock passe par le vrai `normalizeProjectWorkState`, donc pas de faux-vert possible).
**Écarts de contrat à arbitrer (dette, panneau non modifié) :** (1) `ProjectWorkStatePanel.tsx` trie sur `finishedAtMs` jamais émis → tri retombe sur taskId, non chronologique ; (2) `summary` backend non porté par `BackgroundCompletion` → ignoré ; (3) `ownerAgentId`/`projectId` absents du payload par-agent (inoffensif : fallback = agentId). Voir [[workstate-background-tasks-projection-fix]] et [[b8-in-app-trigger-run-in-background]].

View File

@ -0,0 +1,15 @@
---
name: tickets-v1-e2e-validated-qa
description: 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.
metadata:
type: reference
---
Validation QA de bout en bout du système de tickets **V1 (sans attachments)** sur `feature/issue-ticket-system` (backend commité `8de7be0`, frontend non commité). **Verdict : OK.**
**Preuves réelles :**
- `cargo build --workspace` OK. Tests verts sur domain/application ; infrastructure et app-tauri verts **sauf la dette pré-existante déclarée** (`orchestrator_watcher::ask_request_surfaces_reply_alongside_detail` + `app-tauri state::mcp_e2e_loopback_tests::*`, tous `Elapsed(())` du rendez-vous, sans rapport avec les tickets). Aucun échec imputable aux tickets.
- Frontend : `npm run build` OK (tsc+vite), `npm test` = **459 passed / 49 files**.
**Invariants prouvés par tests :** `#N` séquentiel jamais réutilisé (`allocator_never_reuses_numbers`) ; create→read round-trip ; carnet remplaçable & scoped `.ideai/tickets/N/carnet.md` ; pas de self-link (`IssueError::SelfLink`, `domain/issue.rs`) ; assignation agent connu seulement (`create_issue_rejects_unknown_assignee`) ; concurrence optimiste (`update_issue_maps_version_conflict`, `IssueStoreError::VersionConflict`) ; énums fermés statut/priorité.
**Réserve non bloquante (dette technique) :** le conflit de version est détecté côté **front** par fragment de message (`message.includes("version conflict")`, `frontend/src/adapters/ticket.ts`, `useTicketDetail.ts`), s'appuyant sur `domain/ports.rs` `#[error("issue version conflict: …")]`. Un code typé `"versionConflict"` existe DÉJÀ mais uniquement sur la surface MCP (`app-tauri/src/tickets.rs:942`) ; le chemin Tauri command renvoie `INVALID`. Recommandation : propager le code typé dans l'enveloppe d'erreur des `ticket_*` commands et brancher l'UI sur `error.code`. Comportement actuel correct et testé, donc non bloquant.

View File

@ -0,0 +1,19 @@
---
name: ui-rework-sprint-delivered-tickets-21-22-23
description: memory note ui-rework-sprint-delivered-tickets-21-22-23
metadata:
type: project
---
Sprint « UI rework » (order 1) bouclé le 2026-07-07. Les 4 premiers tickets (#16/#17/#18/#19) étaient déjà mergés ; les 3 derniers viennent d'être produits et intégrés. Cadrage : [[ui-rework-sprint-tickets-21-22-23-scoping]].
## Livré (tous verts QA par exécution réelle, mergés --no-ff sur develop)
- **#21** tri des tickets (B+F) — merge `37bf7d4`. Backend : `TicketListQuery.sort?:{field:"number"|"priority"|"status"|"title";direction:"asc"|"desc"}`, appliqué avant pagination, tie-break systématique par `number` croissant. Ordres sémantiques : priority low<medium<high<critical ; status open<inProgress<QA<closed ; title casse-insensible. `sort` absent = comportement historique. Frontend : contrôle « Trier par » dans `TicketFacetsBar` (partagé TicketsPanel + TicketPicker), `sort` dans query+queryKey (reset pagination), curseur reste opaque (G3-bis).
- **#22** docking de views (F pur) merge `2323a71`. Nouvelle primitive `shared/ui/DockRegion` + modèle `features/projects/viewPlacement.ts` : `ViewPlacement = "closed"|"floating"|{dock:"left"|"right"}` par PanelId, invariant un-seul-slot. Ne réutilise NI FloatingWindow NI LayoutTree terminaux (monté chrome-level ProjectsView).
- **#23** fenêtres système (B+F) merge `47b1d64` (HEAD develop). Backend app-tauri : commands `open_view_window({panel,projectId})→{label,url,alreadyOpen}` et `close_view_window(...)→{label,closed}`, vraie WebviewWindow chargeant `index.html?panel=&project=`, registre anti-doublon (label `view-{panel}-{projectIdSansTirets}`), event unique `view-window://lifecycle` payload `{kind:"opened"|"focused"|"closed",panel,projectId,label}`, capability étendue à `view-*`. Frontend : port `WindowGateway` (adapter Tauri + mock), entrée panel-only `app/ViewWindow.tsx` routée dans `main.tsx`, `ViewPanelBody` partagé, `ViewPlacement` étendu à `"detached"`, menu Window + bouton ⤢, garde no-direct-invoke.
## Dette basse restée ouverte (hors périmètre, non bloquante)
- Curseur `ticket_list` toujours offset non opaque/stable (cf. [[ui-rework-sprint-scoping-contracts]]) non soldée par #21.
- Persistance restore-au-redémarrage du docking #22 et du placement détaché #23 : follow-up backend différé (V1 = placement éphémère useState).
## État Git
develop @ `47b1d64` ; branches feature/ticket21-22-23 supprimées (mergées). Rien de sortant, `main` intact. Release `develop→main` en attente de validation utilisateur.

View File

@ -0,0 +1,23 @@
---
name: ui-rework-sprint-scoping-contracts
description: Frontières hexagonales et contrats figés du sprint UI rework — les 4 tickets sont frontend-purs, la popup TicketPicker #18, l'échelle z-index et le curseur opaque.
metadata:
type: reference
---
Sprint « UI rework » (order 1), cadré 2026-07-06. Les **4 tickets sont frontend-purs** : aucun nouveau port/read-model/endpoint.
**Fait clé** : filtrage/recherche tickets déjà backend-driven via `TicketGateway.list(projectId, TicketListQuery{statuses[],priorities[],assignedAgentId,text,limit,cursor})` (ports/index.ts:717) → adapter transmet à `ticket_list`. Client ne fait que le groupement par sprint. #18 réutilise ce contrat, pas d'endpoint dédié.
**G4 (contrat ticket_list) levé pour B** après revue DevBackend : statuses/priorities OK (OR intra / AND inter). Deux écarts en DETTE BASSE : (a) `text` ne matche pas `#ref` (tickets.rs:681, issues.rs:322/326/465) ; (b) `cursor` = offset numérique non opaque/non stable inter-pages (tickets.rs:1231). Acceptable pour picker single-select court.
**G3-bis (garde non-breaking)** : TicketPicker/useTicketSearch traitent `cursor` comme token OPAQUE — ne jamais le construire/incrémenter, ne relayer que le cursor de la page précédente. Migration curseur opaque backend = zéro changement frontend.
**Base de code** : pas de routeur ni store global (navigation = useState local App.tsx + ProjectsView.tsx, sidebar inline ProjectsView.tsx:224). Aucune primitive Modal/Portal partagée ; ~7 features hand-roll `fixed inset-0 role=dialog` z-50/z-[60]. Pas de createPortal. #16 introduit `shared/ui/FloatingWindow` (focus-trap, monté niveau chrome) + `shared/ui/zIndex.ts`.
**Contrat #18 figé**`TicketPicker` props `{open, projectId, title?, confirmLabel?, selectionMode?:"single"|"multi" (défaut single), excludeRefs?: TicketRef[] (filtré client-side), initialQuery?: TicketListQuery, onSelect(TicketPickerResult|[]), onClose}`. `TicketPickerResult={ref,id,number,title,status,priority}`. Extraire `TicketFacetsBar` (fieldsets statut/priorité + recherche depuis TicketsPanel.tsx) + hook `useTicketSearch` (ne PAS réutiliser useTickets, trop lourd). #17 et #19 consomment en single.
**Échelle z-index figée (G2)** : in-cell inchangé (chrome 2-5, F3 z-20, write-portal z-4, resume z-5) ; chrome full-window menuDropdown=40, floatingWindow=50, floatingWindowNested=60, toast=70.
**Règle intégration (G5)** : fenêtres flottantes/menus montées niveau chrome (ProjectsView/App), JAMAIS dans LayoutGrid/LeafView. Ne pas toucher shouldShowWritePortalVeil ni exclusion write-portal↔F3 (cf. [[ticket4-overlay-composition-leafview]]). Focus-trap obligatoire (xterm garde le focus clavier).
**Ordre** : A(#16) ∥ B(#18) racines → prioriser B (chemin critique #17+#19) ; D(#19) après B ; C(#17) après A+B. Tout DevFrontend ; DevBackend = ticket dette basse (matching #ref + curseur opaque/stable).

View File

@ -0,0 +1,39 @@
---
name: ui-rework-sprint-tickets-21-22-23-scoping
description: memory note ui-rework-sprint-tickets-21-22-23-scoping
metadata:
type: project
---
Cadrage hexagonal des 3 derniers tickets du sprint « UI rework » (order 1), fait 2026-07-07 par Architect. Les 4 premiers (#16/#17/#18/#19) sont livrés/mergés sur develop — cf. [[ui-rework-sprint-scoping-contracts]]. Ne pas re-cadrer ; produire.
## État de départ vérifié
- Vues (context/work/tickets/agents/templates/skills/permissions/memory/git) = composants React rendus via menu **View**, pilotés par `openPanel: useState<PanelId|null>` (ProjectsView.tsx:127). UNE seule vue à la fois dans un `FloatingWindow` modal centré (ProjectsView.tsx:497).
- `FloatingWindow` = overlay MODAL (fixed inset-0, backdrop, focus-trap, z-50), non déplaçable/non redimensionnable, purement présentationnel.
- LayoutTree terminaux (cellules/LeafView, layout.json via ProjectStore) = domaine DISTINCT ; ne pas confondre avec le placement des vues.
- `TicketListQuery` (ports/index.ts:717) N'A PAS de sort/order. Pagination RÉELLE (useTicketSearch + loadMore, TicketsPanel.tsx:225 charge 100 puis +100).
## #21 tri tickets (low) — NON frontend-pur : B + F
Le tri est une préoccupation de QUERY, symétrique du filtrage déjà backend-driven (TicketGateway.list→ticket_list). Comme la liste est paginée, trier client ne trie que les pages chargées → FAUX. Refuser le « frontend-pur ».
- **B** : étendre `TicketListQuery`/`ticket_list` avec `sort?:{field:"number"|"priority"|"status"|"title"; direction:"asc"|"desc"}`. ORDRE TOTAL déterministe obligatoire (tie-break par number croissant, sinon curseur casse). priority/status = ordre sémantique enum explicite, pas alpha. Défaut absent = comportement actuel (champ optionnel, rétro-compat). Companion recommandé non imposé : solder la dette basse curseur offset non opaque/stable (cf. [[ui-rework-sprint-scoping-contracts]]) — peut rester ticket séparé.
- **F** : contrôle « Trier par… » dans `TicketFacetsBar` (partagé TicketsPanel + TicketPicker #18). `useTicketSearch` relaie `sort` dans la query, `sort` dans la queryKey (reset pagination). Ne pas toucher le traitement OPAQUE du curseur (G3-bis). Groupement-par-sprint reste client ; tri s'applique intra-groupe.
- Dépend #16/#18 (livrés). Indépendant de #22/#23.
## #22 Anchor/docking views (medium) — frontend-pur V1 ; persistance = B optionnel différé
NE PAS réutiliser FloatingWindow (overlay modal) ni LayoutTree terminaux. NOUVELLE primitive de docking chrome-level, en-flux (pas overlay).
- Frontière : docking = état présentation chrome-level machine-local, distinct du domaine LayoutTree (réservé cellules PTY). Jamais dans LayoutGrid/LeafView (G5).
- Généraliser `openPanel:PanelId|null` en modèle de placement : `ViewPlacement = "closed"|"floating"|{dock:"left"|"right"}` par PanelId — conçu EXTENSIBLE pour #23 (ajoutera "detached"). Invariant : une vue = exactement un slot. V1 reco : 1 vue ancrée par côté, largeur redimensionnable.
- **F** : `shared/ui/DockRegion` (colonne verticale resizable gauche/droite du <main>), header titre + bascule flottant↔ancré. ProjectsView remplace openPanel par le placement. Réutilise composants de vue existants tels quels.
- **B optionnel différé** : persistance restore-au-redémarrage = préférence UI machine-local → store global settings.json/workspace.json (archi §9.2 via ProjectStore), PAS layout.json projet. V1 éphémère (useState) ; persistance = follow-up ticket dédié.
- Autonome. FOURNIT le modèle de placement dont #23 dépend.
## #23 views en fenêtres système (medium) — impact backend Rust + composition root
Cas spécialisé du chantier L10 multi-fenêtre (Tauri v2 WebviewWindow, protocole detach, archi §13.3). Avantage vs detach onglet-terminal : vues gateway/read-model-driven, PAS liées à un Channel PTY → nouvelle WebviewWindow ré-instancie le DI et re-souscrit aux gateways, AUCUN transfert d'état lourd.
- **B (app-tauri)** : command `open_view_window({panel,projectId})` créant une WebviewWindow sur entrée dédiée (URL param ?panel=&project=), lifecycle (focus/close/registre anti-doublon), events cycle de vie (fermeture OS → re-bascule placement). Composition root (di.tsx) : supporter un shell « panneau seul » (mêmes adapters/gateways).
- **F** : nouveau port `WindowGateway.openViewWindow(panel,projectId)` (+ closeViewWindow) avec adapter Tauri + mock (jamais invoke direct). Entrée panel-only lisant panel/project depuis URL. Menu View : action « Ouvrir dans une nouvelle fenêtre ».
- Articulation #22 FIGÉE : `ViewPlacement = "closed"|"floating"|{dock:"left"|"right"}|"detached"`. Une vue = soit ancrée soit flottante soit détachée, jamais deux (même invariant un-seul-slot). #23 = ajoute "detached" + plomberie Tauri.
- DÉPEND du modèle de placement de #22.
## Ordre & dépendances
- #21 en parallèle, autonome (petit B+F, le plus rapide, chaîne tickets uniquement).
- #22 AVANT #23 : #22 pose ViewPlacement que #23 étend. #23 d'abord = réinventer puis retravailler.
- Frontières : #21 seul à toucher domaine tickets (query sort) ; #22 présentation pure (docking ≠ LayoutTree) ; #23 seul à toucher app-tauri/composition root + nouveau port WindowGateway.

View File

@ -0,0 +1,15 @@
---
name: workstate-background-tasks-projection-fix
description: Décision d'archi pour rendre visibles Cancel/Retry dans le panneau Work — extension du read-model GetProjectWorkState, contrat DTO et borne de livraison.
metadata:
type: reference
---
**Défaut** : `AgentWorkState` (`crates/application/src/workstate/mod.rs:140`) ne portait pas les tâches de fond et `GetProjectWorkState` n'avait pas de dépendance `BackgroundTaskStore`. Le panneau Work masque la section (`ProjectWorkStatePanel.tsx:638`, `agent.backgroundTasks.length > 0`) → aucun bouton Cancel/Retry en live. Le frontend était déjà entièrement câblé (`normalizeAgent`/`normalizeBackgroundTask`), il ne manquait que la projection backend.
**Décision (frontière)** : étendre le read-model unique — ajouter `background_tasks: Vec<AgentBackgroundTaskState>` à `AgentWorkState` et brancher `BackgroundTaskStore` via un builder best-effort `with_background_tasks(store)` (calqué sur `with_conversation_sources`), `None` ⇒ zéro régression. **Pas** de fetch séparé côté front (garderait la jointure tâche→agent hors du domaine, casserait l'instantané cohérent, dupliquerait les cycles async). Aucun nouveau port/adapter. `list_background_tasks` (B7) reste comme read-model autonome, hors chemin du panneau.
**Contrat** : `AgentBackgroundTaskState` = miroir de `BackgroundTaskDto` (`dto.rs:2886`) sans owner/project. Projection dans `execute` = union `list_open_for_agent(agent.id)` (per-agent, running/queued/waiting) + `list_undelivered_completions()` (chargé UNE fois avant la boucle, dispatché par `owner_agent_id`, pour failed/cancelled → Retry). Best-effort strict : erreur store ⇒ `Vec::new()` pour l'agent, jamais d'`AppError` (live/busy/tickets intacts).
**Borne V1 assumée** : une tâche terminale **déjà livrée** (wake tiré, `completion_delivered=true`) n'est plus énumérable (droppée des deux listes) → disparaît du panneau ; Retry seulement dans la fenêtre non-livrée. Conforme à la note « retry session-scoped V1 » de `RetryBackgroundTask` (`background/mod.rs:212`). Historique Retry persistant = V2 (ajouterait `list_recent_terminal_for_agent` au port), ticketable si besoin.
**Wiring** : `.with_background_tasks(state.background_task_store.clone())` dans `crates/app-tauri/src/state.rs` (ancre `b7-wiring-anchor-state-rs`) ; le store y est déjà managé (utilisé par `list_background_tasks`). Lié à [[b8-in-app-trigger-run-in-background]], [[b8-command-runner-pty-framing]], [[background-tasks-first-class-design]], [[checkpoint-t1-wake-delivery-bug-fixed-rebuild-pending]].

192
.ideai/permissions.json Normal file
View File

@ -0,0 +1,192 @@
{
"version": 1,
"projectDefaults": {
"rules": [
{
"capability": "read",
"effect": "allow",
"paths": [
"**"
],
"commands": []
},
{
"capability": "write",
"effect": "allow",
"paths": [
"**"
],
"commands": []
},
{
"capability": "delete",
"effect": "allow",
"paths": [
"**"
],
"commands": []
},
{
"capability": "executeBash",
"effect": "allow",
"paths": [],
"commands": []
}
],
"fallback": "allow"
},
"agents": [
{
"agentId": "a6ced819-b893-4213-b003-9e9dc79b9641",
"permissions": {
"rules": [
{
"capability": "read",
"effect": "allow",
"paths": [
"**"
],
"commands": []
},
{
"capability": "write",
"effect": "deny",
"paths": [
"**"
],
"commands": []
},
{
"capability": "delete",
"effect": "allow",
"paths": [
"**"
],
"commands": []
},
{
"capability": "executeBash",
"effect": "allow",
"paths": [],
"commands": []
}
],
"fallback": "allow"
}
},
{
"agentId": "dce19c75-9669-4e45-b8de-9950025157da",
"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"
}
},
{
"agentId": "cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5",
"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"
}
},
{
"agentId": "c3e0d9d8-df36-4b00-b271-62d8aa78892c",
"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"
}
}
]
}

17
.ideai/skills/index.json Normal file
View File

@ -0,0 +1,17 @@
{
"version": 1,
"skills": [
{
"id": "a72dac60-641c-4417-b0d7-94b8539f817a",
"name": "build-appimage",
"description": null,
"contentHash": "77cb33b978b242f6"
},
{
"id": "86ea97df-1533-47e5-8809-dc2b02242567",
"name": "mcp-rendezvous-functional-test",
"description": null,
"contentHash": "9fc8260f64c3b9d5"
}
]
}

View File

@ -0,0 +1,42 @@
# Skill — Test fonctionnel du rendez-vous inter-agents MCP
Workflow **ré-exécutable et évolutif** pour tester de bout en bout le rendez-vous `idea_ask_agent``idea_reply` d'IdeA, du trivial au plus tordu. À relancer après chaque rebuild qui touche l'orchestration MCP / le backstop / la live-state. **Ce plan évolue** : à chaque nouveau souci rencontré, ajoute/raffine un test Tn et note le défaut dans la section « Journal des défauts ».
## Principe
- **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` (ESTAB) et `pgrep -af mcp-server` (2 process par requester = pont vivant).
- 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. 1er tour intact = 1re ligne user `parentUuid:null` = `[IdeA · tâche…]`.
- placement : `.ideai/layouts.json` (agent présent = cellule visible ; absent = background / node_id None).
- live-state : `idea_workstate_read` (last-writer-wins, pas temps réel).
- 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*. Vérifier avant T1 : `stat` mtime de l'AppImage récent + `git log -1` = HEAD attendu.
## Setup avant T1
1. Relancer IdeA, ouvrir le projet, **Main visible** (le demandeur).
2. Garder **2 cellules visibles libres** + lancer **QA et DevFrontend** dans des cellules visibles (cibles chaudes).
3. Laisser **Architect, DevBackend, Git ARRÊTÉS (froids)** : T3 teste le réveil à froid ; T9 utilise Architect+DevBackend froids.
## Méthode d'exécution
On lance dans l'ordre, on **note** chaque verdict avec preuve réelle. Si un défaut **bloquant** apparaît : stop, ouvrir le cycle de fix (Architect→Git→DevBackend→QA, ou via subagents si le rendez-vous lui-même est cassé), rebuild + relance, puis **reprise depuis T1**. Un défaut **non bloquant** est consigné au Journal et on peut continuer si l'utilisateur le décide.
## Ordre des tests (trivial → tordu)
- **T1 — Visibilité outils MCP.** Agent lancé par IdeA voit ses outils sans action manuelle. Vérif : pont ESTAB + 2 mcp-server par requester ; cibles froides = 0 process.
- **T2 — Cible CHAUDE + idea_reply trivial.** ask(agent chaud, « pong via idea_reply »). Attendu : `pong` inline borné, workstate `done`, pas de busy fantôme.
- **T3 — Réveil à FROID + idea_reply.** Cible arrêtée. Attendu : pont relancé (nouveau mcp-server), **1er tour non perdu**, reply remonte.
- **T4 — Cible BACKGROUND (node_id None).** Cible hors layout (sans cellule visible). Attendu : même protocole, multi-tours sans perte.
- **T5 — NO-REPLY (cible répond en prose, pas d'idea_reply).** Attendu : backstop libère le demandeur en temps borné avec `TargetReturnedNoReply` (retryable), **ET live-state de la cible purgée (pas de busy fantôme)**. 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 : 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, 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.
- **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 {working,waiting,blocked} & session morte → `idle` + `STALE_AT_RESTART_MARKER` (use case ReconcileLiveState).
## Critère de fin
Tous les T1→T10 verts avec preuve réelle. Sinon : 1er défaut bloquant = corriger puis reprise T1.
## Journal des défauts (à enrichir au fil des runs)
- **2026-06-24, run a6ced819 (AppImage 08:15, HEAD 1efe2f1)** — T1→T4 ✅. **T5 partiel** : backstop libère le demandeur en ~24 s (`TargetReturnedNoReply` retryable, wedge demandeur corrigé) MAIS la **live-state de la cible n'est pas purgée** : elle reste `status:"working"` jusqu'au prochain write réussi de la cible (re-délégation non bloquée, busy fantôme atténué mais présent → `idea_workstate_read` ment sur la dispo). Cause : backstop agit côté demandeur, ne réinitialise pas la live-state de la cible sur no-reply. → fix en cours.
## Notes / pièges observés
- IdeA peut placer une cible réveillée en **background** même quand des cellules visibles sont libres (observé T3/T4).
- Quand le rendez-vous MCP lui-même est suspecté cassé, **ne pas** orchestrer le fix via `idea_ask_agent` (risque de blocage) : utiliser les subagents natifs de l'orchestrateur pour analyse/fix/rebuild.

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