diff --git a/.ideai/conversations/6bc594e8-a37c-0dbd-1de6-6e3b73002cb4/handoff.md b/.ideai/conversations/6bc594e8-a37c-0dbd-1de6-6e3b73002cb4/handoff.md index 006541d..ffeef2a 100644 --- a/.ideai/conversations/6bc594e8-a37c-0dbd-1de6-6e3b73002cb4/handoff.md +++ b/.ideai/conversations/6bc594e8-a37c-0dbd-1de6-6e3b73002cb4/handoff.md @@ -1,13 +1,9 @@ --- -upTo: 30bb2b67-c173-43d1-9776-48f2f597e90b +upTo: 029988ad-89d3-4a24-8453-f3e0fce922a0 objective: Nouvelle feature cadrée par Architect, prête à démarrer le développement : « Gestion des limites de session des agents » (détection hiérarchique des limites de session + reprise auto annulable). C'est --- **Objectif :** Nouvelle feature cadrée par Architect, prête à démarrer le développement : « Gestion des limites de session des agents » (détection hiérarchique des limites de session + reprise auto annulable). C'est -- **Prompt:** Feature session-limits COMPLÈTE (3 niveaux) et verte. Reste à committer 2 slices, puis on peut envisager le merge d'intégration `feature/agent-session-limits → develop` que tu gardais en attente. État branche actuel : … 9df5923 (LS7 back) · 4fad042 (LS7 front, HEAD). Travail NON committé depuis, à committer maintenant en 2 commits séparés : ═══ COMMIT A — LS8-backend (filet humain niveau 3, backend) ═══ Implémenté par DevBackend, testé par QA (application: 15 tests session_limit_service / app-tauri: 4 wiring, + régressions vertes, 0 failed). Fichiers : - crates/application/src/agent/session_limit.rs — refactor privé `arm_scheduled` (param `resets_at_ms` brut ajouté) partagé par `on_rate_limited` + nouvelle `pub fn confirm_human_resume(agent_id, node_id, conversation_id, resets_at_ms: i64)` (source Human, réutilise la branche Scheduled, annulable). - crates/app-tauri/src/commands.rs — nouvelle commande `set_resume_at(agent_id, resets_at_ms) -> Result<(), ErrorDto>` (résout node_id via node_for_agent + conversation_id best-effort, NOT_FOUND si pas de cellule vivante). - crates/app-tauri/src/lib.rs — `set_resume_at` enregistrée après `cancel_resume`. - crates/application/tests/session_limit_service.rs — +6 tests (QA). - crates/app-tauri/tests/session_limit_wiring.rs — +2 tests (QA). Aucun événement nouveau (réutilise AgentRateLimited + AgentResumeScheduled). ═══ COMMIT B — LS8-front + fix test (DevFrontend a demandé 2 commits ; à toi de voir si tu sépares ou regroupes) ═══ LS8-front (typecheck propre, 109 tests verts) : - frontend/src/ports/index.ts — `setResumeAt(agentId, resetsAtMs)` sur InputGateway. - frontend/src/adapters/input.ts — `setResumeAt` → invoke("set_resume_at", { agentId, resetsAtMs }). - frontend/src/adapters/mock/index.ts — MockInputGateway.setResumeAt (resumeArmings[]). - frontend/src/features/agents/useAgents.ts — action setResumeAt (sans mutation optimiste). - frontend/src/features/agents/AgentLimitBadge.tsx — formulaire de saisie d'heure sur l'état suspected sans heure + helper pur `timeInputToEpochMs` ; TODO LS7 retiré. - frontend/src/features/agents/AgentsPanel.tsx — câblage onSetResumeAt. - frontend/src/features/agents/AgentLimitBadge.test.tsx — tests mis à jour au nouveau contrat + couverture LS8. Fix test hygiène (DevFrontend recommande commit SÉPARÉ) : - frontend/src/adapters/mock/mock.test.ts — compteur gateways 13→14 (« thirteen »→« fourteen » + `permission` dans l'array). Vérifié : 14 gateways réelles. Hors périmètre (NE PAS committer) : .ideai/** (runtime/mémoire), node_modules/ (untracked — DevFrontend signalait qu'il traîne, à gitignorer dans une tâche d'hygiène séparée, hors périmètre ici). QUESTIONS : 1) Committe COMMIT A puis les commits front (LS8-front + fix-test, séparés ou groupés selon ton jugement). Donne-moi les hashes + messages. 2) La suite complète est maintenant verte (Rust: domain/application/app-tauri ; front: agents + adapters/mock 109 tests) et la surface produit session-limits est complète sur les 3 niveaux. Décides-tu MAINTENANT le merge `--no-ff` vers develop (rebase si besoin) ? Si oui, exécute-le et donne-moi le résultat. Si tu veux un dernier garde-fou (ex. run de la suite complète des deux côtés avant merge), dis-le et je le fais lancer. -- **Response:** ✅ 3 commits + merge d'intégration faits. La feature session-limits est intégrée dans `develop`. ═══ 1) Les 3 commits (sur feature/agent-session-limits) ═══ J'ai séparé le fix-test de la feature (hygiène isolée, comme recommandé par DevFrontend) → 3 commits : - **c480d28** `feat(session-limits): LS8-backend — filet humain niveau 3 (set_resume_at)` (session_limit.rs + commands.rs + lib.rs + tests service/wiring ; 5 fichiers, +394/−18) - **5d9dd32** `feat(session-limits): LS8-front — filet humain niveau 3 (saisie d'heure de reprise)` (ports/input/mock + useAgents + AgentLimitBadge(.tsx/.test) + AgentsPanel ; 7 fichiers, +222/−26) - **3f3504e** `fix(test): corrige le compteur de gateways du mock (13 → 14)` (mock.test.ts isolé ; 1 fichier, +2/−1) Artefacts `.ideai/**` et `node_modules/` exclus comme demandé. ═══ 2) Merge `--no-ff` → develop : OUI, exécuté ═══ Décision : la surface produit est complète sur les 3 niveaux et tout est vert des deux côtés → je merge. Pas de rebase nécessaire : `feature` était **12 ahead / 0 behind** `develop` (aucune divergence, base linéaire). - Merge commit : **d7041c5** `merge(session-limits): intégration de la feature limites de session (3 niveaux)` — stratégie ort, **0 conflit**, 47 fichiers / +5157/−45 (cumul LS2→LS8). - `develop` est maintenant à **d7041c5**, contenant toute la chaîne LS2 (a1755e5) → LS8 (3f3504e). - La branche `feature/agent-session-limits` est **conservée** (pas supprimée) : je la garde tant que tu n'as pas confirmé que l'intégration est définitivement validée. Dis-moi si tu veux que je la supprime maintenant. Note d'exécution : les artefacts runtime `.ideai/**` non committés bloquaient le switch de branche → je les ai **stashés le temps du merge puis restaurés** (stash poppé, working tree intact, rien perdu). Aucun de ces artefacts n'est entré dans les commits applicatifs ni dans le merge. ⚠️ Périmètre **strictement local** : aucun `push`. `develop` local est en avance de 58 commits sur `origin/develop` — je ne pousse rien sans ta validation explicite. Prochaines options possibles, à ta main : suppression de `feature/agent-session-limits`, et/ou push de `develop` vers origin (action sortante → nécessite ton feu vert). -- **Response:** Topologie tranchée et opération git exécutée. Le dev démarre sur **`feature/orchestrator-designation`**. **Décision : branche dédiée créée depuis `develop`.** Pourquoi cette base : - HEAD était bien sur `feature/agent-skill-awareness` (pas détaché — le statut initial trompait). - La feature « orchestrateur du projet » est **fonctionnellement indépendante** de skill-awareness. Vérifié au niveau fichiers : leur seul recoupement est `lifecycle.rs`. Les fichiers cœur de ta feature (`context_guard.rs`, `domain/fileguard.rs`, `agent.rs`, `events.rs`, infra `fileguard/mod.rs`) ne sont **pas** touchés par skill-awareness, et `develop` contient déjà le câblage du ContextGuard (commit 8452333) sur lequel ta feature s'appuie. - `feature/agent-skill-awareness` a 4 commits non mergés dans `develop` et **n'est pas confirmé vert** de ton côté → règle d'or : je ne le merge pas et je ne le prends pas comme base (cela tirerait du travail non vérifié dans la nouvelle feature). Branche pure depuis l'intégration = feature mergeable indépendamment. Ce que j'ai fait : 1. Commit de l'état runtime qui traînait dans le working tree (`.ideai/` : conversations, layouts, mémoire + note design non suivie) **sur `feature/agent-skill-awareness`** pour partir d'un arbre propre — `5be8987 chore(wip): état runtime .ideai …`. 2. `checkout develop` → `checkout -b feature/orchestrator-designation`. Base = `8452333` (HEAD de develop). Arbre propre, branche active = `feature/orchestrator-designation`. DevBackend/DevFrontend + QA peuvent attaquer T1..T8 dessus. ⚠️ Point d'attention pour le futur merge : `lifecycle.rs` sera modifié à la fois par cette feature et par skill-awareness (non mergé). À l'intégration de l'une puis l'autre dans `develop`, un conflit sur `lifecycle.rs` est probable — résoluble au merge, rien à anticiper côté dev. Reviens vers moi une fois T1..T8 verts pour le merge `feature/orchestrator-designation → develop`. Note locale uniquement : aucune action sortante (`push`) effectuée. -- **Prompt:** Diagnostic demandé par Main : teste uniquement l’écriture effective dans le `.git` du projet IdeA, de façon minimale et réversible. Commande attendue : créer un fichier temporaire unique sous `/home/anthony/Documents/Projects/IdeA/.git/`, le supprimer immédiatement si la création réussit, puis rapporter le résultat exact (`WRITE_OK` ou l’erreur noyau, notamment `Read-only file system`). Ne lance pas `git add`, `git commit`, ni aucune action Git destructive. Réponds via `idea_reply` si tu reçois ce message comme tâche déléguée. - **Response:** Résultat du test d'écriture minimal dans `/home/anthony/Documents/Projects/IdeA/.git/` : `/usr/bin/bash: line 1: /home/anthony/Documents/Projects/IdeA/.git/.idea-write-test-2-1781903701754795712: Read-only file system` La création a échoué, donc aucun fichier temporaire n'a été créé ni supprimé. Aucune commande Git (`add`, `commit`, etc.) n'a été lancée. - **Prompt:** Contexte: l'utilisateur veut que nous terminions les chantiers ouverts d'IdeA, en autonomie, mais en respectant le cycle Main -> Architect -> Git -> Dev -> QA -> Git. Main ne code pas. Etat local observe par Main: - Branche courante: `feature/orchestrator-designation`. - `git log --oneline --decorate -n 12` montre `8452333 (HEAD -> feature/orchestrator-designation, develop) merge(orchestrator): intègre le câblage du ContextGuard dans develop`, puis `181727d fix(orchestrator): câble le ContextGuard au composition root`, puis `origin/develop` plus ancien. - `git status --short --branch`: worktree dirty avec environ 75 fichiers modifies/non suivis. - Le diff touche notamment `.ideai/*`, `CLAUDE.md`, `crates/app-tauri`, `crates/application`, `crates/domain`, `crates/infrastructure`, `frontend/src/features/projects/ProjectsView.tsx`, `frontend/src/features/terminals/useWritePortal*`, et un nouveau `crates/application/src/diag.rs`. - Les memoires projet indiquent des chantiers ouverts: agent=session vivante coherente, persistance conversationnelle, handoff cross-profile, live-state partage, refresh memoire/contexte pendant la vie d'un agent, UX des delegations/conversations, documentation architecture a resynchroniser. La feature limites de session est indiquee terminee et mergee dans develop. Demande utilisateur: expliquer la situation a Git pour qu'il prenne la meilleure decision sur la gestion des branches, sachant que certains chantiers ont peut-etre des branches deja ouvertes et qu'il faudra peut-etre plusieurs branches. Ta mission Git: 1. Inspecte l'etat git local autant que necessaire. 2. Decide la strategie de branches pour poursuivre ces chantiers sans perdre les changements actuels. 3. Dis a Main sur quelle branche travailler pour le premier chantier logique, si des branches doivent etre creees/switch, et quoi faire du worktree dirty actuel. 4. Ne push pas. Ne fais aucune action sortante. 5. Si tu executes des commandes ou prends une decision, rends compte clairement: branche courante, branches pertinentes, statut dirty, decision et justification. Important: si tu recois cette tache via IdeA, reponds avec `idea_reply`. - **Response:** Décision Git — stratégie de branches pour la suite. ## État constaté (réel) - Branche courante : `feature/orchestrator-designation` @ `8452333`. Elle n'a **aucun commit propre** par rapport à `develop` ; `develop` n'a qu'1 commit de plus = `40982d4 chore(release): passe la version à 0.3.0`. - Worktree dirty = **73 fichiers trackés modifiés + 2 non suivis** (`crates/application/src/diag.rs`, `.ideai/memory/conversation-rotation-safety-design.md`). - Analyse du diff : il est **massivement mono-thème = chantier orchestrateur/designation** (orchestrat ×164, designation ×47) + nouveau sink de diagnostic `diag.rs` pour le rendez-vous inter-agents. Les autres mots-clés (sandbox, fileguard, ratelimit…) sont du bruit de fichiers de test touchés, pas un 2e chantier. - `main` = `29232dd` release 0.3.0 (local, non poussé). `develop` = `40982d4`. ## Audit des branches existantes (vs develop) - `feature/agent-session-limits` → **intégrée dans develop, supprimable** (cohérent avec la mémoire « feature terminée et mergée »). - `feature/agent-skills` → 1 commit non intégré. - `feature/agent-skill-awareness` → 5 commits non intégrés (inclut la lignée skill-awareness + le fix cold-start). - `fix/cold-start-delivery-race` → 3 commits non intégrés (sous-ensemble probable de skill-awareness). ## Ma décision **1. Le worktree dirty est DÉJÀ sur la bonne branche. On n'y touche pas, on ne stashe pas, on ne switche pas.** Ce WIP EST le chantier orchestrateur-designation en cours. Le déplacer ou ouvrir une autre branche par-dessus mélangerait/perdrait ~73 fichiers. Tant qu'il n'est pas figé, `feature/orchestrator-designation` est verrouillée sur ce chantier. **2. Premier chantier logique = FINIR celui-ci (orchestrateur : diag sink + designation), pas en ouvrir un nouveau.** Raison Git : on ne peut pas créer proprement une nouvelle `feature/*` depuis `develop` avec autant de non-commité sur le worktree. Le chemin critique est donc : - Dev finalise sur `feature/orchestrator-designation` → QA verte → **je commit** (commits atomiques : je sépare le code source `crates/` des fichiers runtime `.ideai/*` et de `CLAUDE.md`, qui partent dans un commit `chore` distinct). - Puis **rebase trivial** de la branche sur `develop` (un seul commit d'écart, le bump 0.3.0, aucun conflit attendu) et **merge `--no-ff` → develop**. - Ensuite seulement `develop` redevient une base propre pour la suite. **3. Pour Main, tout de suite :** travaille le **premier chantier sur `feature/orchestrator-designation`** (branche courante, ne rien changer). Confie à Architect le cadrage du périmètre exact « orchestrateur-designation + diag », puis Dev/QA. Quand c'est vert, reviens vers moi pour commit + merge. **4. Ensuite (une fois develop à jour) :** chaque chantier restant indépendant = **une `feature/* dédiée créée depuis develop`** — donc plusieurs branches, une par sujet (persistance conversationnelle, handoff cross-profile, live-state partagé, refresh mémoire/contexte à chaud, UX délégations, resync doc archi). Je créerai chacune au moment où Main me l'annoncera, jamais toutes d'avance. **5. Nettoyage que je propose AVANT d'ouvrir de nouvelles branches** (pour éviter la prolifération) : supprimer `feature/agent-session-limits` (intégrée). Et statuer avec toi sur `feature/agent-skills` / `feature/agent-skill-awareness` / `fix/cold-start-delivery-race` : soit on les intègre dans develop via le cycle (si vivantes et vertes), soit on les abandonne. Dis-moi le sort de chacune ; je n'efface rien sans ton feu vert. Aucune action sortante effectuée. Aucun push, aucun tag, aucune suppression de branche pour l'instant. @@ -23,4 +19,8 @@ objective: Nouvelle feature cadrée par Architect, prête à démarrer le dével - **Response:** Décision Git (aucun commit effectué). ## État constaté - Branche courante : `feature/agent-skill-awareness-v2`, pointée exactement sur `e832af5` = tip de `develop`. `develop` est ancêtre de HEAD → **base saine, aucune divergence** (rebase inutile pour l'instant). - Working tree dirty, deux natures bien distinctes : - **Code (hotfix livraison délégation + logs submit)** — 8 fichiers, +352/-23 : - `crates/app-tauri/src/commands.rs`, `crates/application/src/orchestrator/service.rs`, `crates/infrastructure/src/input/mod.rs` - `frontend/src/adapters/input.ts`, `frontend/src/adapters/terminal.ts`, `frontend/src/domain/index.ts` - `frontend/src/features/terminals/useWritePortal.ts` + `useWritePortal.test.tsx` - **État runtime `.ideai/`** — conversations (handoff/log.jsonl ×3), `layouts.json`, `memory/MEMORY.md`, + nouveau `memory/checkpoint-delivery-submit-logging-fix.md` (non suivi). ## Stratégie de branche **On reste sur `feature/agent-skill-awareness-v2`.** Elle part proprement de `develop`, pas de divergence, c'est le bon support pour reprendre le chantier. Pas de nouvelle branche. (Réserve mineure : le nom de branche parle de « skill-awareness » alors que le diff actuel est un hotfix livraison/logs ; je l'assume car Main reprend ce chantier sous ce nom. Si tu préfères isoler le hotfix sous `fix/delivery-submit-logging`, dis-le, je crée et bascule — sinon on garde.) ## Plan de commit (PLUS TARD, sur ton GO) Deux commits atomiques séparés, par intention : 1. `fix(input): livraison délégation + journalisation submit` → les 8 fichiers code (crates + frontend + test). 2. `chore(wip): état runtime .ideai` → conversations, `layouts.json`, `MEMORY.md` + le nouveau checkpoint mémoire (cohérent avec l'historique `chore(wip)` existant). ## Hors commit / à laisser Rien à exclure ni à ignorer en plus pour l'instant : l'historique du dépôt versionne déjà l'état runtime `.ideai/` via des `chore(wip)`, donc je le committe à part plutôt que de le mélanger au code. (Remarque de fond : ces fichiers runtime sont du bruit de diff ; si tu veux un jour les `.gitignore`, c'est une décision produit séparée à trancher hors de ce ticket.) ## Conditions avant commit / merge - **Avant le commit code** : QA verte — tests Rust (`cargo test` sur les crates touchés) **et** front (`useWritePortal.test.tsx` notamment). Tant que c'est rouge, je ne committe pas le hotfix. - **Avant merge `feature/agent-skill-awareness-v2` → `develop`** : tests verts + rebase sur `develop` uniquement si elle a avancé entre-temps (actuellement non), puis merge `--no-ff`. - **Aucune action sortante** (push/PR) sans ton GO explicite. J'attends ton signal pour committer. - **Prompt:** QA final vert accepté avec réserve environnementale pour `feature/agent-skill-awareness-v2`. Merci de committer localement selon ta stratégie. État attendu: changements code hotfix délégation/logs submit + nouveau changement `crates/application/src/agent/lifecycle.rs` pour awareness skills; fichiers runtime `.ideai/*` modifiés et nouveau checkpoint mémoire. Conditions QA: application/front/infrastructure/app-tauri check verts; tests loopback socket Unix réels non exécutables dans sandbox (`UnixListener::bind` PermissionDenied), alternatives avec skips vertes. Merci de faire des commits atomiques adaptés (tu avais proposé code puis chore runtime), décider si le changement `lifecycle.rs` doit être dans un commit séparé du hotfix ou groupé selon intention, puis retourner hashes, messages, fichiers inclus/exclus, et état final. Pas de push. - **Response:** Commits effectués localement sur `feature/agent-skill-awareness-v2` (aucun push). Décision : `lifecycle.rs` = intention distincte (la feature réelle de la branche) → commit séparé du hotfix. ## 3 commits atomiques (par intention) **1. `befff76` — feat(skills): injecte un paragraphe d'awareness skills dans le fichier de convention** - Inclus : `crates/application/src/agent/lifecycle.rs` - La feature de la branche : `compose_convention_file` émet l'awareness skills (assigné = contexte opérationnel, pas commande magique/sous-tâche ; capitalisation via `idea_create_skill` en MCP / `skill.create` en protocole fichier), sans injecter les corps des skills non assignés. **2. `018eb1a` — fix(input): fiabilise la livraison de délégation et journalise le submit** - Inclus : `crates/app-tauri/src/commands.rs`, `crates/application/src/orchestrator/service.rs`, `crates/infrastructure/src/input/mod.rs`, `frontend/src/adapters/input.ts`, `frontend/src/adapters/terminal.ts`, `frontend/src/domain/index.ts`, `frontend/src/features/terminals/useWritePortal.ts`, `useWritePortal.test.tsx` - Le hotfix livraison délégation + logs submit (bout-en-bout commande Tauri → orchestrateur → file infra → portail front). **3. `cc575ef` — chore(wip): état runtime .ideai (conversations, layouts, mémoire, checkpoint skill-awareness)** - Inclus : `.ideai/conversations/*` (handoff + log.jsonl ×5), `.ideai/layouts.json`, `.ideai/memory/MEMORY.md`, nouveau `.ideai/memory/checkpoint-delivery-submit-logging-fix.md` - État runtime non-code, isolé du code comme convenu. ## Exclus / hors commit Rien laissé de côté : working tree **propre** (`git status` vide). La réserve QA (tests loopback socket Unix réels non exécutables en sandbox — `UnixListener::bind` PermissionDenied, alternatives skips vertes) est consignée dans le message du commit `018eb1a`. ## État final - Branche : `feature/agent-skill-awareness-v2`, tip = `cc575ef`. - Base : toujours `develop` (`e832af5`) comme ancêtre direct, **pas de divergence** → merge `--no-ff` vers `develop` possible sans rebase dès que tu donnes le GO. - Aucune action sortante (pas de push). Dis-moi si tu veux que je merge vers `develop` maintenant ou si on garde sur la feature. -- **Prompt:** Tu viens de committer `feature/agent-skill-awareness-v2` avec QA vert accepté réserve environnementale. Selon les règles projet, Git décide les merges locaux sans demander à l'utilisateur. Merci de trancher maintenant: merge local `feature/agent-skill-awareness-v2` vers `develop` ou différer, avec justification. Si tu décides de merger, fais le merge local approprié sans push et retourne l'état final. Si tu différés, explique la condition restante précise. Ne demande pas de GO utilisateur. \ No newline at end of file +- **Prompt:** Tu viens de committer `feature/agent-skill-awareness-v2` avec QA vert accepté réserve environnementale. Selon les règles projet, Git décide les merges locaux sans demander à l'utilisateur. Merci de trancher maintenant: merge local `feature/agent-skill-awareness-v2` vers `develop` ou différer, avec justification. Si tu décides de merger, fais le merge local approprié sans push et retourne l'état final. Si tu différés, explique la condition restante précise. Ne demande pas de GO utilisateur. +- **Response:** Décision Git : **MERGE effectué** (local, sans push). Feature terminée et QA verte (réserve env. acceptable : seuls les tests loopback socket Unix non exécutables en sandbox, alternatives skips vertes) → rien ne justifiait de différer. ## Ce qui a été fait 1. Pendant l'opération, des écritures runtime live (`.ideai/conversations/6bc594e8…`) ont resurgi et bloquaient le checkout. Je les ai committées proprement sur la feature : - `8074aec` — chore(wip): état runtime .ideai (flux conversation live) 2. `git checkout develop` puis `git merge --no-ff feature/agent-skill-awareness-v2`. - Pas de rebase nécessaire : `develop` était ancêtre direct, historique non divergent. - Merge commit : **`63eb49a`** — merge(skills): intègre agent-skill-awareness-v2 dans develop. ## Historique résultant (develop) ``` * 63eb49a merge(skills): intègre agent-skill-awareness-v2 dans develop |\ | * 8074aec chore(wip): état runtime .ideai (flux conversation live) | * cc575ef chore(wip): état runtime .ideai (…checkpoint skill-awareness) | * 018eb1a fix(input): fiabilise la livraison de délégation et journalise le submit | * befff76 feat(skills): injecte un paragraphe d'awareness skills dans le fichier de convention |/ * e832af5 (base commune) ``` Merge sans conflit (stratégie ort), 22 fichiers / +575 -95. ## État final - Branche courante : **`develop`**, tip = `63eb49a`. - `develop` : **devant `origin/develop` de 15 commits** (local uniquement, aucun push — conforme). - Working tree propre au moment du merge (le flux runtime live peut le re-salir à tout instant, c'est normal). - Branche `feature/agent-skill-awareness-v2` **conservée** (entièrement fusionnée). Je ne la supprime pas : tu as parlé de « reprise de chantier », donc je la garde disponible. Dis-moi si tu veux que je la supprime maintenant qu'elle est intégrée. Aucune action sortante effectuée. Pour publier (`push origin develop`), il me faut ta validation explicite. +- **Prompt:** Inventaire des chantiers en cours après merge local `feature/agent-skill-awareness-v2` dans `develop` (`63eb49a`). Branches visibles: locales `feature/agent-skill-awareness`, `feature/agent-skills`, `fix/cold-start-delivery-race`, `feature/agent-skill-awareness-v2`; distante `origin/feature/agent-session-limits`; develop ahead origin/develop de 15; main ahead origin/main de 4. Merci de déterminer pour chaque branche si elle est déjà intégrée, superseded, encore active ou à conserver, sans suppression pour l'instant. Identifie les chantiers applicatifs réellement en cours/restants et la stratégie repo avant de reprendre le prochain. Ne committe/merge/supprime rien dans cette étape. +- **Response:** Inventaire repo après merge `agent-skill-awareness-v2` → `develop` (`63eb49a`). **Aucune suppression / commit / merge fait** (lecture seule). Méthode : `git cherry` (patch-id) **+** vérification du contenu réel dans `develop`, car les branches sont anciennes et leurs patches ont été re-landés différemment (les patch-ids diffèrent même quand le contenu est présent). ## Statut par branche **`feature/agent-skill-awareness-v2`** — ✅ INTÉGRÉE (mergée à l'instant, `63eb49a`). Conserver tant que reprise possible, sinon supprimable. **`feature/agent-skill-awareness` (v1)** — 🟠 SUPERSEDED par v2. Ses commits uniques portent une **autre approche** : outil MCP `idea_skill_read` + manifeste de skills + brief « capacités IdeA » inconditionnel (`ab34363`, `566bff4`, `1a10d67`). Vérif : `idea_skill_read` **absent de develop** → v2 a délibérément retenu une autre voie (injection des corps de skills dans le fichier de convention + paragraphe d'awareness via `lifecycle.rs`). Son fix cold-start (`e93a2c1`) est déjà couvert par develop. ⇒ rien à récupérer sauf si tu veux ressusciter l'approche `idea_skill_read` (non recommandé, v2 a tranché). **À archiver/supprimer.** **`feature/agent-skills` (L12, `ef101db`)** — 🟢 INTÉGRÉE PAR ÉQUIVALENT. Le domaine skills est présent dans develop : `crates/domain/src/skill.rs`, `crates/application/src/skill/{mod,usecases}.rs`, `crates/infrastructure/src/store/skill.rs` (+ tests). Re-landé via un autre chemin. **Superseded en tant que branche.** **`fix/cold-start-delivery-race` (`9590eac`)** — 🟢 INTÉGRÉE PAR ÉQUIVALENT. La logique cold-start (`release_cold_start`, gate armé) est dans develop : `crates/infrastructure/src/input/mod.rs:341,895`. La branche traîne en plus de vieux `release(0.1.0)/(0.2.0)` → elle a divergé d'un vieux `main`. **Stale, supprimable.** **`origin/feature/agent-session-limits` (`3f3504e`)** — 🟢 MERGÉE (ancêtre de develop). Branche distante stale ; le feature session-limits est dans develop. **`origin/wip/p8c-checkpoint-before-codex`** — branche distante WIP fondations enforcement OS (permissions), non rattachée localement ; à clarifier si encore vivante (probablement absorbée par le chantier permissions/sandbox déjà livré en code). ## État publication (local-only, conforme « pas de push ») - `develop` : **ahead origin/develop de 15** (contient tout ce qui précède). - `main` : **ahead origin/main de 4** = `release(0.3.0)` mergée localement, jamais poussée. origin/main = encore 0.2.0. ## Chantiers applicatifs réellement restants (vs branches mortes) Les 4 branches non-mergées ne portent **aucun chantier vivant** : tout est soit intégré, soit superseded. Le travail restant est ailleurs (cf. mémoire projet, pas dans des branches) : 1. **Validation e2e réelle sur AppImage** — nombreux items « ✓ RÉSOLU EN CODE … valid. e2e restante » (socket MCP, MCP inter-agents au restart, MCP natif en structuré, modèle terminal natif). Bloqueur connu : `checkpoint-blocked-until-appimage-030` / blocage build AppImage 0.3.0. 2. **Enforcement permissions/sandbox** : résiduel `$HOME`/résume du chemin structuré (memory `permissions-sandbox-system-state`). 3. Optionnels persistance : P9 FileGuard, P10 résumé LLM. ## Stratégie repo recommandée avant le prochain chantier - **Nettoyage différé** (sur ton GO, étape suivante) : supprimer en local `feature/agent-skill-awareness`, `feature/agent-skills`, `fix/cold-start-delivery-race` (toutes superseded/intégrées) ; idem branches distantes stale `origin/feature/agent-session-limits` (suppression distante = action sortante → validation explicite requise). - **Prochaine branche** : repartir **de `develop`** (`63eb49a`) avec un `feature/` neuf pour le prochain chantier (probablement la **validation e2e AppImage 0.3.0**, qui est le vrai bloqueur courant). - **Push** : `develop` (+15) et `main` (+4 / release 0.3.0) attendent une validation explicite avant publication — je ne pousse rien sans ton accord. Dis-moi quel chantier on reprend : je crée la branche adéquate depuis `develop`. +- **Prompt:** Démarrage du prochain chantier applicatif recommandé par Architect: `UX conversations/délégations + read-model live-state minimal`. Branche courante attendue `develop` à `63eb49a`, mais des fichiers runtime `.ideai/conversations/6bc594e8...` peuvent être dirty à cause du live. Merci de décider et exécuter la gestion repo locale avant implémentation: créer/basculer sur une branche de feature depuis develop, gérer proprement le dirty runtime sans perdre de données, et retourner branche courante + état. Ne supprime pas les branches obsolètes pour l'instant, ne push pas. \ No newline at end of file diff --git a/.ideai/conversations/6bc594e8-a37c-0dbd-1de6-6e3b73002cb4/log.jsonl b/.ideai/conversations/6bc594e8-a37c-0dbd-1de6-6e3b73002cb4/log.jsonl index c13d023..2227c48 100644 --- a/.ideai/conversations/6bc594e8-a37c-0dbd-1de6-6e3b73002cb4/log.jsonl +++ b/.ideai/conversations/6bc594e8-a37c-0dbd-1de6-6e3b73002cb4/log.jsonl @@ -37,3 +37,7 @@ {"id":"c554b89b-b920-4d50-b387-a315bb494c5a","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781945808651,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"QA final vert accepté avec réserve environnementale pour `feature/agent-skill-awareness-v2`. Merci de committer localement selon ta stratégie. État attendu: changements code hotfix délégation/logs submit + nouveau changement `crates/application/src/agent/lifecycle.rs` pour awareness skills; fichiers runtime `.ideai/*` modifiés et nouveau checkpoint mémoire. Conditions QA: application/front/infrastructure/app-tauri check verts; tests loopback socket Unix réels non exécutables dans sandbox (`UnixListener::bind` PermissionDenied), alternatives avec skips vertes. Merci de faire des commits atomiques adaptés (tu avais proposé code puis chore runtime), décider si le changement `lifecycle.rs` doit être dans un commit séparé du hotfix ou groupé selon intention, puis retourner hashes, messages, fichiers inclus/exclus, et état final. Pas de push."} {"id":"601fabf2-4a39-45aa-a153-81637732f09c","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781945860170,"source":{"kind":"agent","agentId":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"},"role":"response","text":"Commits effectués localement sur `feature/agent-skill-awareness-v2` (aucun push). Décision : `lifecycle.rs` = intention distincte (la feature réelle de la branche) → commit séparé du hotfix.\n\n## 3 commits atomiques (par intention)\n\n**1. `befff76` — feat(skills): injecte un paragraphe d'awareness skills dans le fichier de convention**\n- Inclus : `crates/application/src/agent/lifecycle.rs`\n- La feature de la branche : `compose_convention_file` émet l'awareness skills (assigné = contexte opérationnel, pas commande magique/sous-tâche ; capitalisation via `idea_create_skill` en MCP / `skill.create` en protocole fichier), sans injecter les corps des skills non assignés.\n\n**2. `018eb1a` — fix(input): fiabilise la livraison de délégation et journalise le submit**\n- Inclus : `crates/app-tauri/src/commands.rs`, `crates/application/src/orchestrator/service.rs`, `crates/infrastructure/src/input/mod.rs`, `frontend/src/adapters/input.ts`, `frontend/src/adapters/terminal.ts`, `frontend/src/domain/index.ts`, `frontend/src/features/terminals/useWritePortal.ts`, `useWritePortal.test.tsx`\n- Le hotfix livraison délégation + logs submit (bout-en-bout commande Tauri → orchestrateur → file infra → portail front).\n\n**3. `cc575ef` — chore(wip): état runtime .ideai (conversations, layouts, mémoire, checkpoint skill-awareness)**\n- Inclus : `.ideai/conversations/*` (handoff + log.jsonl ×5), `.ideai/layouts.json`, `.ideai/memory/MEMORY.md`, nouveau `.ideai/memory/checkpoint-delivery-submit-logging-fix.md`\n- État runtime non-code, isolé du code comme convenu.\n\n## Exclus / hors commit\nRien laissé de côté : working tree **propre** (`git status` vide). La réserve QA (tests loopback socket Unix réels non exécutables en sandbox — `UnixListener::bind` PermissionDenied, alternatives skips vertes) est consignée dans le message du commit `018eb1a`.\n\n## État final\n- Branche : `feature/agent-skill-awareness-v2`, tip = `cc575ef`.\n- Base : toujours `develop` (`e832af5`) comme ancêtre direct, **pas de divergence** → merge `--no-ff` vers `develop` possible sans rebase dès que tu donnes le GO.\n- Aucune action sortante (pas de push).\n\nDis-moi si tu veux que je merge vers `develop` maintenant ou si on garde sur la feature."} {"id":"30bb2b67-c173-43d1-9776-48f2f597e90b","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781945865963,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Tu viens de committer `feature/agent-skill-awareness-v2` avec QA vert accepté réserve environnementale. Selon les règles projet, Git décide les merges locaux sans demander à l'utilisateur. Merci de trancher maintenant: merge local `feature/agent-skill-awareness-v2` vers `develop` ou différer, avec justification. Si tu décides de merger, fais le merge local approprié sans push et retourne l'état final. Si tu différés, explique la condition restante précise. Ne demande pas de GO utilisateur."} +{"id":"48a2b2a1-bc6c-4dc9-8a26-2a32489a997a","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781945918036,"source":{"kind":"agent","agentId":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"},"role":"response","text":"Décision Git : **MERGE effectué** (local, sans push). Feature terminée et QA verte (réserve env. acceptable : seuls les tests loopback socket Unix non exécutables en sandbox, alternatives skips vertes) → rien ne justifiait de différer.\n\n## Ce qui a été fait\n1. Pendant l'opération, des écritures runtime live (`.ideai/conversations/6bc594e8…`) ont resurgi et bloquaient le checkout. Je les ai committées proprement sur la feature :\n - `8074aec` — chore(wip): état runtime .ideai (flux conversation live)\n2. `git checkout develop` puis `git merge --no-ff feature/agent-skill-awareness-v2`.\n - Pas de rebase nécessaire : `develop` était ancêtre direct, historique non divergent.\n - Merge commit : **`63eb49a`** — merge(skills): intègre agent-skill-awareness-v2 dans develop.\n\n## Historique résultant (develop)\n```\n* 63eb49a merge(skills): intègre agent-skill-awareness-v2 dans develop\n|\\\n| * 8074aec chore(wip): état runtime .ideai (flux conversation live)\n| * cc575ef chore(wip): état runtime .ideai (…checkpoint skill-awareness)\n| * 018eb1a fix(input): fiabilise la livraison de délégation et journalise le submit\n| * befff76 feat(skills): injecte un paragraphe d'awareness skills dans le fichier de convention\n|/\n* e832af5 (base commune)\n```\nMerge sans conflit (stratégie ort), 22 fichiers / +575 -95.\n\n## État final\n- Branche courante : **`develop`**, tip = `63eb49a`.\n- `develop` : **devant `origin/develop` de 15 commits** (local uniquement, aucun push — conforme).\n- Working tree propre au moment du merge (le flux runtime live peut le re-salir à tout instant, c'est normal).\n- Branche `feature/agent-skill-awareness-v2` **conservée** (entièrement fusionnée). Je ne la supprime pas : tu as parlé de « reprise de chantier », donc je la garde disponible. Dis-moi si tu veux que je la supprime maintenant qu'elle est intégrée.\n\nAucune action sortante effectuée. Pour publier (`push origin develop`), il me faut ta validation explicite."} +{"id":"77e0f1c6-fcb4-4d4f-8279-40e0a3e9945c","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781946275638,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Inventaire des chantiers en cours après merge local `feature/agent-skill-awareness-v2` dans `develop` (`63eb49a`). Branches visibles: locales `feature/agent-skill-awareness`, `feature/agent-skills`, `fix/cold-start-delivery-race`, `feature/agent-skill-awareness-v2`; distante `origin/feature/agent-session-limits`; develop ahead origin/develop de 15; main ahead origin/main de 4. Merci de déterminer pour chaque branche si elle est déjà intégrée, superseded, encore active ou à conserver, sans suppression pour l'instant. Identifie les chantiers applicatifs réellement en cours/restants et la stratégie repo avant de reprendre le prochain. Ne committe/merge/supprime rien dans cette étape."} +{"id":"70c220d9-29cd-49d0-abe6-f6dcbbdc108b","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781946373176,"source":{"kind":"agent","agentId":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"},"role":"response","text":"Inventaire repo après merge `agent-skill-awareness-v2` → `develop` (`63eb49a`). **Aucune suppression / commit / merge fait** (lecture seule). Méthode : `git cherry` (patch-id) **+** vérification du contenu réel dans `develop`, car les branches sont anciennes et leurs patches ont été re-landés différemment (les patch-ids diffèrent même quand le contenu est présent).\n\n## Statut par branche\n\n**`feature/agent-skill-awareness-v2`** — ✅ INTÉGRÉE (mergée à l'instant, `63eb49a`). Conserver tant que reprise possible, sinon supprimable.\n\n**`feature/agent-skill-awareness` (v1)** — 🟠 SUPERSEDED par v2. Ses commits uniques portent une **autre approche** : outil MCP `idea_skill_read` + manifeste de skills + brief « capacités IdeA » inconditionnel (`ab34363`, `566bff4`, `1a10d67`). Vérif : `idea_skill_read` **absent de develop** → v2 a délibérément retenu une autre voie (injection des corps de skills dans le fichier de convention + paragraphe d'awareness via `lifecycle.rs`). Son fix cold-start (`e93a2c1`) est déjà couvert par develop. ⇒ rien à récupérer sauf si tu veux ressusciter l'approche `idea_skill_read` (non recommandé, v2 a tranché). **À archiver/supprimer.**\n\n**`feature/agent-skills` (L12, `ef101db`)** — 🟢 INTÉGRÉE PAR ÉQUIVALENT. Le domaine skills est présent dans develop : `crates/domain/src/skill.rs`, `crates/application/src/skill/{mod,usecases}.rs`, `crates/infrastructure/src/store/skill.rs` (+ tests). Re-landé via un autre chemin. **Superseded en tant que branche.**\n\n**`fix/cold-start-delivery-race` (`9590eac`)** — 🟢 INTÉGRÉE PAR ÉQUIVALENT. La logique cold-start (`release_cold_start`, gate armé) est dans develop : `crates/infrastructure/src/input/mod.rs:341,895`. La branche traîne en plus de vieux `release(0.1.0)/(0.2.0)` → elle a divergé d'un vieux `main`. **Stale, supprimable.**\n\n**`origin/feature/agent-session-limits` (`3f3504e`)** — 🟢 MERGÉE (ancêtre de develop). Branche distante stale ; le feature session-limits est dans develop.\n\n**`origin/wip/p8c-checkpoint-before-codex`** — branche distante WIP fondations enforcement OS (permissions), non rattachée localement ; à clarifier si encore vivante (probablement absorbée par le chantier permissions/sandbox déjà livré en code).\n\n## État publication (local-only, conforme « pas de push »)\n- `develop` : **ahead origin/develop de 15** (contient tout ce qui précède).\n- `main` : **ahead origin/main de 4** = `release(0.3.0)` mergée localement, jamais poussée. origin/main = encore 0.2.0.\n\n## Chantiers applicatifs réellement restants (vs branches mortes)\nLes 4 branches non-mergées ne portent **aucun chantier vivant** : tout est soit intégré, soit superseded. Le travail restant est ailleurs (cf. mémoire projet, pas dans des branches) :\n1. **Validation e2e réelle sur AppImage** — nombreux items « ✓ RÉSOLU EN CODE … valid. e2e restante » (socket MCP, MCP inter-agents au restart, MCP natif en structuré, modèle terminal natif). Bloqueur connu : `checkpoint-blocked-until-appimage-030` / blocage build AppImage 0.3.0.\n2. **Enforcement permissions/sandbox** : résiduel `$HOME`/résume du chemin structuré (memory `permissions-sandbox-system-state`).\n3. Optionnels persistance : P9 FileGuard, P10 résumé LLM.\n\n## Stratégie repo recommandée avant le prochain chantier\n- **Nettoyage différé** (sur ton GO, étape suivante) : supprimer en local `feature/agent-skill-awareness`, `feature/agent-skills`, `fix/cold-start-delivery-race` (toutes superseded/intégrées) ; idem branches distantes stale `origin/feature/agent-session-limits` (suppression distante = action sortante → validation explicite requise).\n- **Prochaine branche** : repartir **de `develop`** (`63eb49a`) avec un `feature/` neuf pour le prochain chantier (probablement la **validation e2e AppImage 0.3.0**, qui est le vrai bloqueur courant).\n- **Push** : `develop` (+15) et `main` (+4 / release 0.3.0) attendent une validation explicite avant publication — je ne pousse rien sans ton accord.\n\nDis-moi quel chantier on reprend : je crée la branche adéquate depuis `develop`."} +{"id":"029988ad-89d3-4a24-8453-f3e0fce922a0","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781946459657,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Démarrage du prochain chantier applicatif recommandé par Architect: `UX conversations/délégations + read-model live-state minimal`. Branche courante attendue `develop` à `63eb49a`, mais des fichiers runtime `.ideai/conversations/6bc594e8...` peuvent être dirty à cause du live. Merci de décider et exécuter la gestion repo locale avant implémentation: créer/basculer sur une branche de feature depuis develop, gérer proprement le dirty runtime sans perdre de données, et retourner branche courante + état. Ne supprime pas les branches obsolètes pour l'instant, ne push pas."} diff --git a/.ideai/conversations/7a2f446c-2efa-0c56-08dd-07cdc5cac19b/handoff.md b/.ideai/conversations/7a2f446c-2efa-0c56-08dd-07cdc5cac19b/handoff.md index 95f0966..c7521e8 100644 --- a/.ideai/conversations/7a2f446c-2efa-0c56-08dd-07cdc5cac19b/handoff.md +++ b/.ideai/conversations/7a2f446c-2efa-0c56-08dd-07cdc5cac19b/handoff.md @@ -1,11 +1,9 @@ --- -upTo: 506b5f0c-e7c2-457e-81cf-a22d5ac5ac97 +upTo: 9dc7772c-d574-470e-a792-56a71d4a85cc objective: CADRAGE ARCHITECTURE (pas de code) — Support de la délégation inter-agents (idea_ask_agent/idea_reply) pour les profils CODEX. ## Contexte / gap déjà localisé Le round-trip inter-agent fonctionne pour --- **Objectif :** CADRAGE ARCHITECTURE (pas de code) — Support de la délégation inter-agents (idea_ask_agent/idea_reply) pour les profils CODEX. ## Contexte / gap déjà localisé Le round-trip inter-agent fonctionne pour -- **Prompt:** Validation d'approche AVANT dev — lot LP4-4 : étendre l'enforcement OS Landlock au chemin structuré (sessions Claude/Codex en mode JSON), aujourd'hui non sandboxé. État actuel (committé, vert) : - Domaine pur : `domain::sandbox` avec `SandboxPlan`, `SandboxContext`, `compile_sandbox_plan(eff, ctx) -> Option`, et le port `SandboxEnforcer { fn enforce(&self, &SandboxPlan) -> Result; fn kind(); }`. Adapters infra : `LandlockSandbox` (Linux), `NoopSandbox`, `default_enforcer()`. - Chemin PTY (`crates/infrastructure/src/pty/mod.rs`) : OS-enforcé. Technique retenue = `spawn_command_sandboxed` : un THREAD JETABLE appelle `enforcer.enforce(plan)` (restriction Landlock irréversible, donc confinée au thread) PUIS spawn le child depuis ce thread → le domaine Landlock est hérité par le child via fork+exec. portable-pty n'expose pas de pre_exec injectable, d'où ce choix ; il évite aussi le piège de l'allocation non async-signal-safe dans un pre_exec post-fork en process multithreadé. - Chemin structuré (`crates/infrastructure/src/session/process.rs::drain`) : spawn via `tokio::process::Command` (async), draine stdout ligne-à-ligne jusqu'à EOF. `SpawnLine` { command, args, cwd, env, stdin } ne porte aucun plan. C'est l'incarnation « un exec par tour ». Question d'archi à trancher : comment enforcer le `SandboxPlan` sur le child spawné par `tokio::process::Command` en respectant l'hexagonal ET la sûreté (le truc du thread jetable du PTY ne transpose pas tel quel au spawn async tokio qui forke sur les threads du runtime) ? Pistes à arbitrer : (a) `CommandExt::pre_exec` (tokio le réexpose) appelant l'enforce dans le child post-fork — simple mais risque async-signal-safety si `landlock` alloue ; (b) déporter le spawn du tour structuré sur un thread dédié restreint (via `spawn_blocking` + thread jetable comme le PTY), au prix de la nature async du drain ; (c) un helper de spawn sandboxé partagé entre PTY et session (factoriser la technique) ; (d) autre. Livrable attendu (via idea_reply) : la stratégie retenue + justification (sûreté + hexagonal), le contrat à modifier (faut-il que `SpawnLine` porte le plan ? l'enforcer est-il injecté dans la session factory comme il l'est dans le PTY adapter ?), le découpage des fichiers à toucher, et les invariants/tests que QA devra vérifier. NE code rien. Si une piste est dangereuse (ex. allocation post-fork), dis-le explicitement. -- **Response:** # LP4-4 — Validation d'approche : enforcement Landlock sur le chemin structuré ## Verdict Stratégie retenue : **(b) raffiné — spawn du tour structuré sandboxé sur un thread jetable restreint, en spawn `std` synchrone**, exposé à l'async via `spawn_blocking`. C'est la transposition directe et sûre de la technique déjà prouvée du PTY. **Piste (a) `pre_exec(enforce)` REJETÉE** comme dangereuse (détail plus bas). **(c) factorisation** : oui sur le *principe*, non sur le *corps* — les deux spawns sont trop différents (portable-pty `SlavePty` vs `std::process`). --- ## Pourquoi PAS (a) `pre_exec(enforce)` — DANGER explicite `tokio::process::Command` réexpose bien `CommandExt::pre_exec`, mais le closure s'exécute **dans l'enfant après `fork`, avant `exec`**, dans un process **multithreadé** (les workers du runtime tokio). Après `fork` en contexte multithreadé, seules les opérations **async-signal-safe** sont permises : tout mutex tenu par un autre thread au moment du fork (typiquement le lock de l'arène malloc) reste verrouillé à jamais dans l'enfant. Or `landlock::Ruleset::…restrict_self()` **alloue** (construction du ruleset, `RestrictionStatus`, Vec internes) → `malloc` post-fork → **risque de deadlock de l'enfant**. C'est exactement le piège que le commentaire du PTY (`spawn_command_sandboxed`, lignes 185-206) documente et évite. La cohérence d'archi impose de le rejeter ici aussi. > Note : il *existe* une variante async-signal-safe de Landlock (construire le ruleset_fd dans le parent, ne faire que `prctl(NO_NEW_PRIVS)` + `landlock_restrict_self(fd)` — deux syscalls purs — dans le pre_exec). Mais elle force à **scinder le port `SandboxEnforcer` en deux phases** (prepare allouant / commit syscall-only) et fait fuiter cette mécanique dans le domaine. Inutile : la technique du thread jetable atteint la même sûreté **sans toucher au contrat de port**. Je la mentionne pour mémoire, je ne la recommande pas. ## Pourquoi (b) est sûr La technique du PTY ne fait **rien** dans l'enfant post-fork : `enforce(plan)` tourne dans le **thread jetable parent AVANT le fork** ; l'enfant **hérite** simplement le domaine Landlock (hérité across `fork`, préservé across `execve`). Zéro code post-fork ⇒ **zéro problème d'async-signal-safety**. C'est toute l'élégance, et elle transpose telle quelle. La seule difficulté est que `tokio::process::Command` **forke sur un worker partagé du runtime** (qu'on ne peut pas restreindre : la restriction est irréversible → on empoisonnerait le runtime). D'où : pour le chemin sandboxé on **abandonne le drain async tokio** au profit d'un **drain `std` synchrone sur le thread jetable restreint**, réconcilié à l'async par `spawn_blocking`. Le chemin non-sandboxé (`sandbox == None` **ou** pas d'enforcer) **reste l'actuel drain async tokio, inchangé** (zéro régression, c'est aussi le seul chemin sur non-Linux). Détails de sûreté du thread sandboxé : 1. `enforcer.enforce(&plan)` restreint CE thread (fail-closed : `Err` ⇒ on échoue le tour, **aucun child ne tourne**) ; 2. `std::process::Command::spawn()` depuis ce thread ⇒ l'enfant hérite le domaine ; 3. poser un `unsafe { cmd.pre_exec(|| Ok(())) }` **vide** (async-signal-safe) pour **forcer le chemin `fork`+`exec`** déterministe (parité avec portable-pty, lève tout doute vs un éventuel `posix_spawn` glibc — l'héritage tiendrait de toute façon, mais on ne parie pas) ; 4. drain bloquant ligne-à-ligne stdin/stdout → EOF → `wait()` → `Vec` ; 5. le thread meurt, emportant sa restriction irréversible ; les autres threads d'IdeA sont intouchés. **Timeout** : aujourd'hui `run_turn` enveloppe le `drain` async. En sandboxé, on enveloppe le `JoinHandle` du thread via `tokio::time::timeout` ; à expiration il faut **tuer le child** (le thread est bloqué en read). Donc le thread renvoie son *killer* (pid / `Arc>`) par un `oneshot` dès après spawn ; le kill provoque l'EOF ⇒ le read débloque ⇒ le thread finit ⇒ on retourne `Timeout`. À implémenter proprement (c'est le seul vrai surcoût de machinerie vs l'élégance actuelle). --- ## Contrat à modifier 1. **`SpawnLine` porte le plan** (oui) — `crates/infrastructure/src/session/process.rs` : ajouter `pub sandbox: Option`. Symétrie avec `SpawnSpec.sandbox`. `SpawnLine` est un DTO **infra** (pas domaine), donc OK. 2. **L'enforcer est injecté dans la factory** (oui, comme le PTY adapter) — `StructuredSessionFactory` gagne un champ `Option>` + un builder `with_sandbox_enforcer(...)`, jumeau exact de `PortablePtyAdapter::with_sandbox_enforcer`. **Pas** dans la signature du port : c'est une dépendance de composition root, par-instance, pas par-appel. 3. **Le plan traverse le port par-appel** — le `SandboxPlan` dépend des permissions résolues de l'agent, il est calculé par-lancement dans `lifecycle.rs` step 5d (`spec.sandbox`). Il doit donc passer **dans `AgentSessionFactory::start`** : ajouter `sandbox: Option<&SandboxPlan>`. `SandboxPlan` est un type **domaine** (`domain::sandbox`) franchissant un **port domaine** — cohérent (déjà le cas via `SpawnSpec.sandbox` sur `AgentRuntime`). Extension O/C : une seule vraie impl + les fakes. Flux complet : `lifecycle.rs` (calcule `spec.sandbox`) → passe le plan à `launch_structured` (qui ne reçoit pas `spec` aujourd'hui) → `factory.start(..., sandbox)` → la factory apparie `sandbox` (plan, par-appel) + son enforcer (par-instance) et les passe à `ClaudeSdkSession::new` / `CodexExecSession::new` → l'adapter les stocke, remplit `SpawnLine.sandbox`, et passe l'enforcer à `run_turn`. 4. **`run_turn`** — `crates/infrastructure/src/session/process.rs` : signature `run_turn(spec, enforcer: Option<&Arc>, timeout)`. Si `spec.sandbox.is_some() && enforcer.is_some()` ⇒ drain sandboxé (thread restreint) ; sinon ⇒ `drain` async actuel **strictement inchangé**. --- ## Découpage des fichiers à toucher - `crates/domain/src/ports.rs:537` — `AgentSessionFactory::start` : + `sandbox: Option<&SandboxPlan>`. - `crates/infrastructure/src/session/process.rs` — champ `SpawnLine.sandbox` ; `run_turn` reçoit l'enforcer ; nouveau `drain_sandboxed` (thread jetable + std spawn + pre_exec vide + timeout par kill). - `crates/infrastructure/src/session/factory.rs` — champ `Option>` + `with_sandbox_enforcer` ; `start` apparie plan+enforcer et les injecte dans les ctors d'adapters. - `crates/infrastructure/src/session/claude.rs` (`build_spawn_line` ~L187, `send` ~L195) & `codex.rs` (~L162/L195) — stocker plan+enforcer, remplir `SpawnLine.sandbox`, passer l'enforcer à `run_turn`. - `crates/application/src/agent/lifecycle.rs` — `launch_structured` (~L1620) reçoit le plan (`spec.sandbox`) et le relaie à `factory.start`. - `crates/app-tauri/src/state.rs:408` — `StructuredSessionFactory::new().with_sandbox_enforcer(infrastructure::default_enforcer())`. - **Fakes à mettre à jour** (nouvelle signature `start`) : `crates/domain/tests/structured_session_d0.rs`, `crates/application/tests/structured_launch_d3.rs`, `crates/application/tests/orchestrator_service.rs`. --- ## Invariants & tests pour la QA 1. **Parité avec le PTY (le test pivot)** : réplique de `pty_spawn_enforces_sandbox_plan_end_to_end` côté structuré, avec un **fake CLI / `sh`** qui émet une ligne JSONL et tente d'écrire **hors** grant (doit être bloqué kernel) et **dans** grant (doit réussir). **Zéro token** (aucun vrai claude/codex). Gardé derrière `landlock_is_enforced()` (skip propre sur kernel sans Landlock). 2. **Companion négatif** : même factory+enforcer mais `spec.sandbox == None` ⇒ l'écriture hors-grant **réussit** (prouve que le blocage vient du plan, pas d'une restriction ambiante). 3. **Fail-closed** : posture `Deny` sur kernel sans Landlock ⇒ `enforce` `Err` ⇒ `run_turn` renvoie une erreur et **aucun child ne tourne** (assert : le marqueur de sortie du fake CLI n'existe pas). 4. **No-op par défaut** : `eff == None` ⇒ `compile_sandbox_plan` `None` ⇒ `spec.sandbox None` ⇒ chemin async tokio actuel, comportement natif (régression nulle). Vérifier que la suite structurée existante (conformance, D0/D3) reste **verte sans modification de comportement**. 5. **Confinement de l'irréversibilité** : après un tour sandboxé, un **autre** tour (autre session, plan plus large) sur le même process IdeA n'est PAS affecté par la restriction du tour précédent (le thread jetable est mort). Test : deux tours successifs avec des grants disjoints, chacun voit son propre périmètre. 6. **Timeout sous sandbox** : un fake CLI qui ne ferme jamais stdout ⇒ `run_turn(timeout)` tue le child et renvoie `Timeout`, sans laisser de zombie ni de thread bloqué. 7. **Resume préservé** : le `conversation_id` est toujours capté correctement après un tour sandboxé (la restriction FS ne casse pas le parsing du `session_id`). ## ⚠️ Risque produit à signaler (hors mécanisme, mais bloquant à valider) Les CLI structurées (claude/codex = binaires Node) ont des besoins FS ambiants **bien plus lourds** qu'un `sh` : lecture de `~/.claude` / `~/.codex` (credentials, cache de session pour le resume), `node_modules`, libs système, écriture de caches temporaires. `compile_sandbox_plan` ne **fence en écriture/lecture que les classes explicitement posées** et garde les lectures globalement ouvertes — mais si une policy pose un `Deny`/posture restrictive touchant `$HOME`, le **resume peut casser** (la CLI n'écrit plus son cache de session). Recommandation : LP4-4 livre le **mécanisme** validé au fake CLI (zéro token, points 1-7), et on **flag** qu'une validation e2e manuelle d'un vrai tour claude/codex sous un plan représentatif doit confirmer que le run dir + le home de la CLI restent atteignables avant d'activer le sandbox en prod pour le chemin structuré. C'est un sujet de **composition du plan** (run_dir reachability, déjà réservé dans `SandboxContext.run_dir` mais non consommé par la traduction pure), pas du mécanisme d'enforcement — à traiter en lot suivant si besoin. --- **Résumé** : (b) avec thread jetable restreint + std spawn + `spawn_blocking`, fail-closed identique au PTY ; `SpawnLine.sandbox` ajouté ; enforcer injecté par construction dans la factory ; plan passé par-appel via `AgentSessionFactory::start(.., sandbox)`. (a) rejetée (alloc post-fork). Ne rien coder avant ce GO — QA doit pouvoir s'appuyer sur les 7 invariants ci-dessus. - **Prompt:** Arbitrage LP4-4 — une divergence est remontée par DevBackend sur ton cadrage, elle touche un invariant crate-wide. Verdict requis. Ton cadrage demandait, dans `drain_sandboxed` (chemin structuré), un `unsafe { cmd.pre_exec(|| Ok(())) }` VIDE pour forcer std sur le chemin déterministe fork+exec (parité avec portable-pty). Blocage : la crate `infrastructure` est `#![forbid(unsafe_code)]` (lib.rs:12). Un `forbid` ne peut pas être relâché par un `#[allow]` local. Le PTY n'avait jamais eu besoin d'unsafe car il hérite le fork+exec du pre_exec INTERNE de portable-pty ; sur le chemin structuré on pilote `std::process` en direct, donc le pre_exec serait à nous → unsafe → interdit. DevBackend a retenu (et livré, build+tests verts) l'option (a) : RETIRER le pre_exec. Son argument : `landlock_restrict_self` restreint le thread courant et toute sa descendance ; l'héritage est assuré par le noyau à travers fork/clone/vfork ET préservé par execve, Y COMPRIS via posix_spawn (= clone+execve), car l'enforcement vit au niveau des credentials de la tâche, hors d'atteinte de l'espace utilisateur. Le fork+exec n'était donc qu'une garantie de DÉTERMINISME du syscall de spawn, pas de sécurité ; enforce()-avant-spawn-sur-le-même-thread suffit. Les deux options sur la table : (a) rester comme livré : zéro unsafe, héritage noyau (choix par défaut de DevBackend). (b) passer lib.rs de `#![forbid(unsafe_code)]` à `#![deny(unsafe_code)]` + `#[allow(unsafe_code)]` scoppé sur drain_sandboxed pour rétablir le pre_exec vide. Question : valides-tu (a) — l'héritage de la restriction Landlock est-il bien garanti par le noyau indépendamment de fork+exec vs posix_spawn, rendant le pre_exec inutile à la sécurité — ou exiges-tu (b) (relâcher l'invariant unsafe-code de la crate) ? Si (a), confirme qu'on garde `#![forbid(unsafe_code)]` intact. Réponds avec le verdict + justification courte ; c'est juste cet arbitrage, pas une re-revue complète. - **Response:** # Verdict LP4-4 : **(a) validée — on garde `#![forbid(unsafe_code)]` intact** DevBackend a raison, et son choix est même **cohérent avec mon cadrage initial** : j'y avais explicitement écrit que l'héritage tient sans le pre_exec (« even without it inheritance holds across posix_spawn's clone »), le pre_exec vide n'étant qualifié que d'« assurance de déterminisme », **jamais** de garantie de sécurité. Le retirer ne retire donc aucune propriété de sûreté. ## Justification technique (l'héritage est bien garanti par le noyau) - L'enforcement Landlock est attaché aux **credentials de la tâche** (le domaine Landlock vit dans la `cred`, sous NO_NEW_PRIVS — que `restrict_self` pose lui-même). C'est de l'état **noyau**, hors d'atteinte de l'espace utilisateur. - `landlock_restrict_self` restreint le **thread appelant** ; tout enfant créé **par ce thread** hérite ses credentials → donc le domaine Landlock. L'héritage se fait à travers `fork`/`clone`/`vfork` et est **préservé par `execve`**. - `posix_spawn` (glibc) = `clone(CLONE_VM|CLONE_VFORK)` + `execve` émis **depuis le thread appelant** dans le même process : l'enfant hérite les creds exactement comme via fork+exec. Le mécanisme de spawn ne change que le **déterminisme du syscall**, pas l'héritage. La seule précondition de sûreté — **le syscall de spawn doit être émis par le thread restreint** — est respectée par le design : `enforce(plan)` puis `Command::spawn()` sur le **même** thread jetable. ✔ ## Confirmation empirique décisive Le test e2e de parité (écriture hors-grant **bloquée** kernel / dans-grant réussie) passe sur le chemin structuré avec le spawn réellement utilisé. C'est la **preuve in vivo** que l'héritage tient indépendamment de fork+exec vs posix_spawn — exactement l'invariant en débat. Build + suite verts ⇒ rien à rouvrir. ## Arbitrage de l'invariant crate-wide Relâcher `#![forbid(unsafe_code)]` → `deny + #[allow]` scoppé pour ne récupérer qu'une *garantie de déterminisme de spawn* (sans valeur de sécurité) serait un **mauvais échange** : on dégraderait une protection statique crate-wide pour une commodité nulle côté sûreté. **Non.** **Décision : on reste en (a). `crates/infrastructure/src/lib.rs:12` `#![forbid(unsafe_code)]` reste INTACT. Pas de pre_exec, pas d'unsafe.** Une seule exigence pour QA, à garder verte en permanence (déjà couverte par le test de parité) : l'invariant **« écriture hors-grant bloquée sur le chemin structuré »** est le garde-fou qui détecterait toute régression d'héritage si le mécanisme de spawn venait à changer. Tant qu'il est vert, (a) est prouvée. - **Prompt:** Cadrage architecture — nouvelle feature « Gestion des limites de session des agents » (détection + reprise auto). Étape 1 du cycle §3, AVANT tout code. Produis la cartographie : frontières domaine/application/infra, ports/contrats à créer ou étendre, et l'arborescence des fichiers touchés. Mets aussi à jour ARCHITECTURE.md. CONTEXTE PRODUIT (verrouillé avec l'utilisateur le 2026-06-16) : Besoin : IdeA doit savoir quand un agent est en limite de session ET jusqu'à quelle heure, puis lui demander de reprendre où il en était une fois la limite levée. Priorités : (1) SOLIDE — pas de bidouille, marche dans ~100% des cas même pour un novice ; (2) si possible sans dépendance au modèle de l'agent. CONSTAT DUR à intégrer : l'heure exacte de reset n'existe nulle part de façon universelle (ni OS, ni code de sortie, ni API inter-modèles). Elle est fabriquée par le fournisseur et seulement exposée dans le flux de sa CLI. Donc « 100% fiable + zéro dépendance modèle + heure exacte » sont incompatibles simultanément. SOLUTION RETENUE — détecteur HIÉRARCHIQUE calqué sur la hiérarchie de readiness existante (domain/readiness.rs) : - Niveau 1 (solide, structuré) : l'adapter structuré extrait limite + reset du flux machine. Pour Claude, `rate_limit_event.rate_limit_info` est DÉJÀ parsé dans infrastructure/session/claude.rs (~ligne 90) mais jeté (réduit à Heartbeat) — il suffit de lire le timestamp de reset (resetsAt) au lieu de le dropper. - Niveau 2 (déclaratif, configurable) : champ de profil `rate_limit_pattern` (regex + groupe de capture pour l'heure) pour agents PTY/TUI sans adapter structuré, dans la lignée des profils déclaratifs §9 (domain/profile.rs). - Niveau 3 (filet humain) : si rien ne matche mais agent `Stalled` (variante DÉJÀ prévue dans domain/readiness.rs), IdeA DEMANDE à l'utilisateur. Garantit le « 100% même pour un novice » : jamais d'inaction silencieuse. MODEL-AGNOSTIC tenu AU DOMAINE : le domaine ne connaît que quelque chose comme `RateLimited { until: Option }`. Tout le savoir spécifique modèle reste confiné aux adapters/profils. REPRISE (model-agnostique, briques existantes) : pivot sur le `conversation_id` du moteur + `--resume` natif, déjà câblés (session/claude.rs build_spawn_line + application/agent/resume.rs ListResumableAgents). Le `--resume` porte tout l'historique → pas de reconstruction manuelle. Le SessionInspector (infrastructure/inspector/claude.rs) fournit le « dernier sujet » pour l'UI. Un planificateur arme un réveil sur le port Clock (infrastructure/clock/) à resets_at puis relance via SessionPlan::Resume + prompt de reprise court. DÉCISIONS PRODUIT VERROUILLÉES : - Reprise : AUTOMATIQUE à l'heure de reset, ANNULABLE (fenêtre + notification UI). - Couverture : les TROIS niveaux d'emblée (y compris le repli regex niveau 2). - État : EN MÉMOIRE uniquement — PAS de persistance de SessionLimit. Conséquence assumée : le réveil auto ne joue que tant qu'IdeA reste ouvert ; si l'IDE est fermé/rouvert après le reset, le chemin existant ListResumableAgents (agent_was_running/conversation_id) prend le relais. DÉCOUPAGE PRESSENTI (à valider/affiner par toi) : 1) domaine (variante ReplyEvent::RateLimited, ReadinessSignal::RateLimited, type SessionLimit, état/statut agent RateLimited) ; 2) adapter Claude (extraire resetsAt) ; 3) profil (champ rate_limit_pattern) ; 4) application (service de planification de reprise sur le port Clock, annulable) ; 5) UI front (badge « limité jusqu'à HH:MM » + filet humain de confirmation). Livrable attendu : la cartographie complète (ports à créer/étendre avec leurs signatures, où vit chaque pièce, fichiers à créer/modifier, lots ordonnés pour le cycle dev/test), + ARCHITECTURE.md mis à jour. Signale tout point où ma solution entre en tension avec l'archi hexagonale existante. @@ -23,4 +21,6 @@ objective: CADRAGE ARCHITECTURE (pas de code) — Support de la délégation int - **Prompt:** Tu es sollicité par Main pour reprendre après le checkpoint AppImage 0.3.0. Contexte utile: le chantier `orchestrator-designation` est intégré localement sur `develop` (develop ahead origin, AppImage 0.3.0 produite). Le prochain chantier recommandé par Git est `feature/agent-skill-awareness`, mais il faut d'abord trancher son chevauchement avec une branche/initiative `feature/agent-skills` mentionnée dans les notes. Merci de cadrer précisément: 1) objectif produit/technique de `agent-skill-awareness`, 2) différence avec `agent-skills` si visible depuis le repo ou les notes, 3) frontières backend/frontend/docs, 4) contrats/ports/DTO à créer ou modifier, 5) risques et ordre d'implémentation. Ne code pas; donne un cadrage actionnable pour Git puis DevBackend/DevFrontend/QA. - **Response:** ## Cadrage `feature/agent-skill-awareness` État repo constaté : `develop` est ahead origin et contient déjà L12 `agent-skills` dans le code courant (`Skill`, `SkillStore`, CRUD, assignation agent↔skill, injection des bodies dans le convention file). La branche `feature/agent-skill-awareness` diverge avant l’intégration `orchestrator-designation`; son diff est très large et mêlé à des changements runtime/anciens. Recommandation Git : **ne pas merger la branche brute**. Rejouer sélectivement les contrats utiles sur une branche neuve depuis `develop`. ## 1) Objectif produit/technique Objectif produit : un agent doit savoir qu’il possède des skills assignés et comment les utiliser, sans que l’utilisateur doive le lui rappeler. Aujourd’hui L12 injecte le contenu complet des skills dans `# Skills`, mais c’est bas dans le contexte, lu comme documentation, et pas présenté comme affordance/action disponible. Objectif technique minimal : transformer l’injection “dump de contenu” en modèle “à la MCP” pour les profils MCP : - section haute altitude `# Skills disponibles`, juste après l’orchestration/capacités IdeA, listant les skills assignés par `name + description` ; - outil MCP read-only `idea_skill_read(name)` pour charger le body complet à la demande ; - champ optionnel `description` sur `Skill`, avec fallback déterministe via `effective_description()` ; - rétrocompat des anciens `skills/index.json` sans `description` ; - conserver un mode non-MCP compatible. Point à trancher avec Architecture : soit garder l’ancien dump complet pour `mcp == None`, soit intégrer cette découverte au futur binaire universel `idea`/skill built-in. Ne pas mélanger avec la refonte C-univ complète. La note de branche ajoute aussi un brief inconditionnel “capacités IdeA” dans `compose_convention_file`. Attention : `ARCHITECTURE.md` récent pousse une décision plus structurante : remplacer la prose libre d’orchestration par un **skill built-in `Orchestration IdeA`** (`SkillScope::Builtin`). Donc, pour ce chantier, je recommande de **ne pas reprendre tel quel le brief inconditionnel** sauf comme correctif transitoire validé par Architecture. Le périmètre propre de `agent-skill-awareness` doit rester : “découverte et lecture des skills assignés”. ## 2) Différence avec `feature/agent-skills` `agent-skills` visible dans le repo = L12, déjà intégré fonctionnellement : - domaine : `Skill`, `SkillScope::{Global, Project}`, `SkillRef`, `Agent.skills`/`ManifestEntry.skills` ; - port : `SkillStore` ; - infra : `FsSkillStore` global + projet ; - application : `CreateSkill`, `UpdateSkill`, `ListSkills`, `DeleteSkill`, `AssignSkillToAgent`, `UnassignSkillFromAgent` ; - backend Tauri + DTO ; - frontend : `features/skills`, `SkillGateway`, assignation dans `AgentsPanel` ; - lancement : `LaunchAgent` résout les skills assignés et injecte leurs bodies dans `compose_convention_file`. `agent-skill-awareness` = couche par-dessus L12 : - rend les skills visibles comme capacités nommées ; - évite de forcer le body complet en contexte MCP ; - expose une lecture explicite du body via `idea_skill_read`; - ajoute `description` comme méta courte, pas une nouvelle famille de skills. Donc ce n’est pas un doublon de `agent-skills`; c’est une amélioration d’ergonomie runtime. Mais son ancienne branche embarque des changements qui chevauchent des zones modifiées depuis, donc reprise manuelle. ## 3) Frontières backend/frontend/docs Backend Domaine : - ajouter `description: Option` à `Skill` avec `#[serde(default)]` ; - ajouter `Skill::with_description` et `Skill::effective_description()` ; - préserver `with_content()` en conservant la description ; - éventuellement ajouter `OrchestratorCommand::ReadSkill { name, requester? }` et action `skill.read` dans `OrchestratorRequest::validate` si on garde le routage MCP via modèle orchestrator. Backend Application : - `CreateSkillInput` reçoit `description: Option` ; - `UpdateSkill` doit idéalement pouvoir modifier `description` aussi, pas seulement `content`, sinon le frontend ne peut pas éditer la méta ; - créer `ReadSkill` use case read-only sur le port existant `SkillStore`, pas de nouveau port ; - résolution par nom : project scope d’abord, global ensuite ; ambiguïté dans un même scope = erreur typée ; absent = not found ; case-insensitive. Backend Lifecycle : - modifier `compose_convention_file` pour les profils MCP : section `# Skills disponibles` en amont, lignes déterministes `**name** — description`, mentionnant `idea_skill_read(name=...)` ; - garder ordre déterministe des skills assignés selon le manifest ; - décider comportement non-MCP. Option conservatrice : garder le dump `# Skills` complet seulement en non-MCP pour zéro régression. Option cible architecture : passer par skill built-in + futur CLI `idea`, mais c’est un autre lot. Infrastructure / MCP : - ajouter `idea_skill_read` au catalogue MCP et au mapping tool → `OrchestratorCommand::ReadSkill` ; - dispatcher dans `OrchestratorService` vers `ReadSkill`, retour inline Markdown ; - câbler dans `state.rs`/composition root ; - mettre à jour les tests de compteur/catalogue MCP, actuellement sensibles aux nombres fixes. App-Tauri DTO/commands : - `SkillDto` bénéficie du champ automatiquement si `Skill` sérialise camelCase ; - `CreateSkillRequestDto` et `UpdateSkillRequestDto` doivent porter `description?: string | null` ; - commandes UI existantes `create_skill`/`update_skill` restent les mêmes noms. Frontend : - `domain Skill` ajoute `description?: string | null` ; - `CreateSkillInput` ajoute `description?: string`; `updateSkill` doit permettre de passer description + content, pas seulement content ; - `SkillEditor` ajoute un champ court “Description” ; en edit, description éditable ; - `SkillsPanel` peut afficher description sous le nom ; - mocks + tests RTL à adapter. Docs : - `ARCHITECTURE.md` : ajouter la décision “awareness MCP” sous §14.2 ou l’aligner avec §16 si le skill built-in devient la voie cible ; - `agents-dev/L12-skills.md` ou note dédiée : préciser que L12 crée/assigne/injecte, et que `agent-skill-awareness` ajoute description + affordance + read tool. ## 4) Contrats / ports / DTO À créer/modifier : - `domain::Skill { description: Option }` avec serde default. - `Skill::effective_description() -> String` : description non vide trimée, sinon première ligne non vide du body sans `#` initial. - `SkillStore` : **pas de nouveau port**. Les impls `list/get/save` transportent simplement le champ. - `FsSkillStore` index : ajouter `description` dans `IndexEntry`, `#[serde(default)]`, écriture camelCase. Le body reste dans `md/.md`. - `CreateSkillInput { name, description, content, scope, project_root }`. - `UpdateSkillInput` à faire évoluer vers `{ scope, skill_id, description, content, project_root }` ou variante patch explicite. Je conseille simple remplacement complet `description + content` pour rester aligné UI. - nouveau use case `ReadSkill { SkillStore }` : input `{ name, project_root }`, output `MarkdownDoc` ou DTO `{ name, scope, contentMd }` si on veut plus de traçabilité. Branche historique renvoyait seulement `MarkdownDoc`; acceptable pour MCP. - `OrchestratorRequest`: action/type `skill.read`, champ `name` requis. - `OrchestratorCommand::ReadSkill { name, requester? }`. Le `requester` est utile si la couche MCP veut garder la symétrie avec context/memory, mais le use case n’en a pas besoin. - MCP tool `idea_skill_read`: input `{ name: string }`, output contenu Markdown inline. - DTO Tauri/TS : `Skill.description?: string | null`, create/update requests. À ne pas créer : - pas de `SkillAwarenessStore` ; - pas de nouveau port dédié ; - pas de mécanisme CLI propriétaire ; - pas de lancement/exécution de skill depuis l’UI. ## 5) Risques et ordre d’implémentation Risques : - la branche historique est obsolète vis-à-vis de `orchestrator-designation`; merge brut très risqué ; - conflit conceptuel avec la décision architecture `SkillScope::Builtin` / “Orchestration IdeA” : ne pas figer de prose libre qui sera supprimée juste après ; - double noms de skills : project shadow global doit être documenté ; doublons intra-scope doivent produire une erreur claire ; - assignation à chaud : un skill assigné pendant une session ne devient visible qu’après relaunch/régénération du convention file, sauf mécanisme futur ; - ancien index sans description : serde default obligatoire ; - tests MCP avec compteurs hardcodés fragiles ; préférer assertion par présence de tool. Ordre recommandé : 1. **Git** : créer une branche neuve depuis `develop`, par exemple `feature/agent-skill-awareness-v2`; ne cherry-pick que si les hunks sont triviaux, sinon réimplémenter depuis la note. Garder `feature/agent-skill-awareness` comme référence de design/test, pas comme base de merge. 2. **DevBackend T1** : domaine + serde + tests purs (`description`, fallback, `with_content` conserve description, legacy JSON). 3. **DevBackend T2** : `FsSkillStore`, use cases create/update/list, DTO Tauri. Tests store legacy + roundtrip. 4. **DevBackend T3** : `ReadSkill` + `OrchestratorCommand::ReadSkill` + validation `skill.read`. Tests résolution project/global/ambiguous/not found. 5. **DevBackend T4** : MCP catalogue/mapping/service/state. Tests tool map + dispatch + catalogue par nom. 6. **DevBackend T5** : `compose_convention_file` awareness. Tests : MCP avec skills affiche `# Skills disponibles`, descriptions, appel `idea_skill_read`, pas de body complet si décision retenue ; non-MCP conserve baseline/dump complet ; zéro skill omet la section ; ordre avant persona ou juste après orchestration selon décision. 7. **DevFrontend T6** : champ description dans domain/ports/adapters/mock/SkillEditor/SkillsPanel/tests. Ne pas toucher à l’exécution de skills. 8. **Docs T7** : architecture + agents-dev, en explicitant la frontière avec futur `SkillScope::Builtin`. 9. **QA T8** : `cargo test --workspace`, `pnpm test`, puis e2e AppImage : agent neuf + skill assigné + profil MCP voit `# Skills disponibles`, appelle `idea_skill_read`, reçoit le body ; profil non-MCP ne régresse pas. Verdict court : `agent-skills` = socle déjà intégré ; `agent-skill-awareness` = affordance + lecture à la demande. Reprendre le chantier, oui, mais en branche neuve depuis `develop`, avec périmètre serré et sans avaler le vieux diff. - **Prompt:** Reprise chantier `feature/agent-skill-awareness-v2` après hotfix livraison délégation/logs submit. Contexte: branche actuelle `feature/agent-skill-awareness-v2`; dirty attendu avec fichiers runtime `.ideai/*` et changements code du hotfix listés dans la mémoire `checkpoint-delivery-submit-logging-fix`. Le checkpoint précédent disait de cadrer `agent-skill-awareness` vs `agent-skills` avant implémentation. Merci de fournir le cadrage architecture: objectif exact, frontières backend/frontend, contrats/DTO/ports à toucher, et ordre d'implémentation recommandé. Ne code pas. -- **Response:** ## Cadrage architecture — `feature/agent-skill-awareness-v2` ### Verdict de cadrage Il faut distinguer strictement deux sujets : - **`agent-skills` / L12** = fonctionnalité déjà existante : entité `Skill`, scopes `Global|Project`, CRUD, assignation agent↔skill dans le manifeste, injection des bodies assignés dans le convention file à l’activation. - **`agent-skill-awareness`** = rendre l’agent conscient du système de skills IdeA et de la manière correcte de les utiliser/contribuer, sans réimplémenter L12. Donc le chantier recommandé n’est pas un nouveau store, ni une nouvelle UI CRUD, ni un mécanisme de slash-commands fournisseur. C’est une évolution de **composition de contexte agent** + éventuellement une petite surface de découverte orchestrateur, gardée séparée. ### Objectif exact MVP recommandé : à chaque activation d’agent, le convention file doit expliquer explicitement : 1. Les sections sous `# Skills` sont les workflows assignés à cet agent, utilisables quand pertinents. 2. Un skill assigné est du contexte opérationnel, pas une commande magique ni une sous-tâche fournisseur. 3. Si l’agent identifie un workflow réutilisable, il doit passer par l’orchestration IdeA (`idea_create_skill` côté MCP, ou `skill.create` côté protocole fichier), jamais écrire directement dans `.ideai/skills/`. 4. Les skills non assignés ne doivent pas être injectés intégralement à tous les agents : l’assignation reste la frontière de contexte. Ce MVP ferme le flou `awareness` vs `skills` : on garde L12 comme source métier, on améliore la compréhension de l’agent au moment où son contexte est généré. ### Frontières backend À toucher : - `crates/application/src/agent/lifecycle.rs` - `compose_convention_file(...)` est le point naturel : fonction pure, déjà responsable de `Project root`, orchestration, contexte projet, persona, skills, mémoire, handoff. - Ajouter une sous-section courte, stable et testable, par exemple dans `# Orchestration IdeA` ou juste avant `# Skills` : `## Usage des skills IdeA`. - Garder l’ordre actuel : project root → orchestration/awareness → contexte projet → persona → skills → mémoire → handoff. - Tests application de composition dans le même fichier ou suite existante : - agent sans skills : la consigne awareness peut exister, mais pas de section `# Skills` si la liste est vide, pour préserver le contrat actuel. - agent avec skills : la consigne précède les bodies et les bodies restent en ordre manifeste. - `mcp_enabled=true` : mentionner les outils `idea_create_skill` / outils natifs IdeA. - `mcp_enabled=false` : mentionner le protocole fichier `skill.create`. À ne pas toucher pour le MVP : - Pas de nouveau `SkillStore`. - Pas de nouveau port domaine. - Pas de nouveau DTO Tauri. - Pas de mutation du manifeste. - Pas de changement des invariants `Skill`, `SkillRef`, `Agent.skills`. - Pas de scope `Builtin` tant que le projet reste sur l’état réel actuel : l’architecture historique en parle, mais le code courant a déjà une prose d’orchestration dynamique et le pivot structuré/MCP est livré différemment. Réintroduire `Builtin` serait un autre chantier. ### Frontières frontend MVP : **aucune frontière frontend obligatoire**. L’UI skills existe déjà via : - `frontend/src/domain/index.ts` : `Skill`, `SkillRef`, `SkillScope`. - `frontend/src/ports/index.ts` : `SkillGateway`. - `frontend/src/adapters/skill.ts` : `list/create/update/delete/assign/unassign`. - `frontend/src/features/skills/*` : panneau et view-model L12. Éventuel ajustement UI, à garder non bloquant : afficher dans le panneau skills une phrase sobre du type “Les skills assignés sont injectés au lancement de l’agent”. Pas de nouveau gateway pour ça. ### Contrats/DTO/ports à toucher MVP recommandé : - **Domaine Rust** : aucun nouveau type requis. - **Ports Rust** : aucun nouveau port. - **Application** : seulement la fonction pure de composition du convention file et ses tests. - **Infrastructure** : aucun changement. - **Tauri DTO/commands** : aucun changement. - **Frontend DTO/ports** : aucun changement. Contrats existants à respecter : - `domain::Skill { id, name, content_md, scope }`. - `domain::SkillRef { skill_id, scope }` stocké sur l’agent/manifeste. - `SkillStore::list/get/save/delete` reste la seule abstraction de persistance. - `LaunchAgent::resolve_skills` reste best-effort pour les dangling refs : un skill supprimé ne bloque pas le launch. - `compose_convention_file` reste pure/I-O free. ### Option séparée : découverte typée des skills par agent À ne faire que si le produit veut que les agents découvrent les skills non assignés. Dans ce cas, ne pas injecter tous les bodies. Ajouter plutôt une surface compacte : - `OrchestratorCommand::ListSkills { scope: Option }` ou `ListSkills` avec scope requis. - Alias protocole : `skill.list`. - Outil MCP : `idea_list_skills(scope?)`. - `OrchestratorService` réutilise le `SkillStore` existant et renvoie une liste compacte `{ id, name, scope }`, pas `contentMd` par défaut. Ce serait un lot séparé, parce que cela touche `domain/src/orchestrator.rs`, `application/src/orchestrator/service.rs`, l’adapter MCP / watcher, et éventuellement les DTO de réponse. Ce n’est pas nécessaire pour corriger l’awareness des skills assignés. ### Ordre d’implémentation recommandé 1. **Stabiliser le texte de contrat** - Rédiger une section courte “Usage des skills IdeA”. - Deux variantes : MCP (`idea_create_skill`) et fichier (`skill.create`). - Garder l’interdiction des subagents natifs dans la section orchestration existante. 2. **Modifier `compose_convention_file` uniquement** - Ajouter un helper pur si utile, par exemple `compose_skill_awareness(mcp_enabled: bool) -> &'static str`. - Ne pas déplacer la section `# Skills` ni changer la forme des bodies. 3. **Ajouter les tests de composition** - No-skills : pas de `# Skills`, awareness présente. - With-skills : awareness + bodies dans l’ordre. - MCP vs file : bonne consigne de création/contribution. 4. **Vérifier non-régression launch** - Tests ciblés application `agent/lifecycle`. - Puis `cargo test -p application agent` ou le subset existant pertinent. - Pas besoin de Vitest sauf si un texte UI est ajouté. 5. **Lot optionnel discovery** seulement après validation du MVP - Décider explicitement si un agent doit pouvoir lister les skills non assignés. - Si oui, implémenter `skill.list` / `idea_list_skills` comme nouvelle entrée orchestrateur compacte. ### Point d’attention Le fichier `ARCHITECTURE.md` contient encore des sections historiques sur un vieux plan `Builtin skill + idea CLI + inbox/outbox`, mais l’état réel du code est déjà sur `AskAgent`, `Reply`, sessions structurées, MCP bridge, mailbox/input mediator. Pour ce chantier, il faut suivre l’état réel du code et ne pas rouvrir l’ancien plan. Le bon axe est : **améliorer la conscience contextuelle des agents sur les skills existants**, pas refaire l’orchestration. \ No newline at end of file +- **Response:** ## Cadrage architecture — `feature/agent-skill-awareness-v2` ### Verdict de cadrage Il faut distinguer strictement deux sujets : - **`agent-skills` / L12** = fonctionnalité déjà existante : entité `Skill`, scopes `Global|Project`, CRUD, assignation agent↔skill dans le manifeste, injection des bodies assignés dans le convention file à l’activation. - **`agent-skill-awareness`** = rendre l’agent conscient du système de skills IdeA et de la manière correcte de les utiliser/contribuer, sans réimplémenter L12. Donc le chantier recommandé n’est pas un nouveau store, ni une nouvelle UI CRUD, ni un mécanisme de slash-commands fournisseur. C’est une évolution de **composition de contexte agent** + éventuellement une petite surface de découverte orchestrateur, gardée séparée. ### Objectif exact MVP recommandé : à chaque activation d’agent, le convention file doit expliquer explicitement : 1. Les sections sous `# Skills` sont les workflows assignés à cet agent, utilisables quand pertinents. 2. Un skill assigné est du contexte opérationnel, pas une commande magique ni une sous-tâche fournisseur. 3. Si l’agent identifie un workflow réutilisable, il doit passer par l’orchestration IdeA (`idea_create_skill` côté MCP, ou `skill.create` côté protocole fichier), jamais écrire directement dans `.ideai/skills/`. 4. Les skills non assignés ne doivent pas être injectés intégralement à tous les agents : l’assignation reste la frontière de contexte. Ce MVP ferme le flou `awareness` vs `skills` : on garde L12 comme source métier, on améliore la compréhension de l’agent au moment où son contexte est généré. ### Frontières backend À toucher : - `crates/application/src/agent/lifecycle.rs` - `compose_convention_file(...)` est le point naturel : fonction pure, déjà responsable de `Project root`, orchestration, contexte projet, persona, skills, mémoire, handoff. - Ajouter une sous-section courte, stable et testable, par exemple dans `# Orchestration IdeA` ou juste avant `# Skills` : `## Usage des skills IdeA`. - Garder l’ordre actuel : project root → orchestration/awareness → contexte projet → persona → skills → mémoire → handoff. - Tests application de composition dans le même fichier ou suite existante : - agent sans skills : la consigne awareness peut exister, mais pas de section `# Skills` si la liste est vide, pour préserver le contrat actuel. - agent avec skills : la consigne précède les bodies et les bodies restent en ordre manifeste. - `mcp_enabled=true` : mentionner les outils `idea_create_skill` / outils natifs IdeA. - `mcp_enabled=false` : mentionner le protocole fichier `skill.create`. À ne pas toucher pour le MVP : - Pas de nouveau `SkillStore`. - Pas de nouveau port domaine. - Pas de nouveau DTO Tauri. - Pas de mutation du manifeste. - Pas de changement des invariants `Skill`, `SkillRef`, `Agent.skills`. - Pas de scope `Builtin` tant que le projet reste sur l’état réel actuel : l’architecture historique en parle, mais le code courant a déjà une prose d’orchestration dynamique et le pivot structuré/MCP est livré différemment. Réintroduire `Builtin` serait un autre chantier. ### Frontières frontend MVP : **aucune frontière frontend obligatoire**. L’UI skills existe déjà via : - `frontend/src/domain/index.ts` : `Skill`, `SkillRef`, `SkillScope`. - `frontend/src/ports/index.ts` : `SkillGateway`. - `frontend/src/adapters/skill.ts` : `list/create/update/delete/assign/unassign`. - `frontend/src/features/skills/*` : panneau et view-model L12. Éventuel ajustement UI, à garder non bloquant : afficher dans le panneau skills une phrase sobre du type “Les skills assignés sont injectés au lancement de l’agent”. Pas de nouveau gateway pour ça. ### Contrats/DTO/ports à toucher MVP recommandé : - **Domaine Rust** : aucun nouveau type requis. - **Ports Rust** : aucun nouveau port. - **Application** : seulement la fonction pure de composition du convention file et ses tests. - **Infrastructure** : aucun changement. - **Tauri DTO/commands** : aucun changement. - **Frontend DTO/ports** : aucun changement. Contrats existants à respecter : - `domain::Skill { id, name, content_md, scope }`. - `domain::SkillRef { skill_id, scope }` stocké sur l’agent/manifeste. - `SkillStore::list/get/save/delete` reste la seule abstraction de persistance. - `LaunchAgent::resolve_skills` reste best-effort pour les dangling refs : un skill supprimé ne bloque pas le launch. - `compose_convention_file` reste pure/I-O free. ### Option séparée : découverte typée des skills par agent À ne faire que si le produit veut que les agents découvrent les skills non assignés. Dans ce cas, ne pas injecter tous les bodies. Ajouter plutôt une surface compacte : - `OrchestratorCommand::ListSkills { scope: Option }` ou `ListSkills` avec scope requis. - Alias protocole : `skill.list`. - Outil MCP : `idea_list_skills(scope?)`. - `OrchestratorService` réutilise le `SkillStore` existant et renvoie une liste compacte `{ id, name, scope }`, pas `contentMd` par défaut. Ce serait un lot séparé, parce que cela touche `domain/src/orchestrator.rs`, `application/src/orchestrator/service.rs`, l’adapter MCP / watcher, et éventuellement les DTO de réponse. Ce n’est pas nécessaire pour corriger l’awareness des skills assignés. ### Ordre d’implémentation recommandé 1. **Stabiliser le texte de contrat** - Rédiger une section courte “Usage des skills IdeA”. - Deux variantes : MCP (`idea_create_skill`) et fichier (`skill.create`). - Garder l’interdiction des subagents natifs dans la section orchestration existante. 2. **Modifier `compose_convention_file` uniquement** - Ajouter un helper pur si utile, par exemple `compose_skill_awareness(mcp_enabled: bool) -> &'static str`. - Ne pas déplacer la section `# Skills` ni changer la forme des bodies. 3. **Ajouter les tests de composition** - No-skills : pas de `# Skills`, awareness présente. - With-skills : awareness + bodies dans l’ordre. - MCP vs file : bonne consigne de création/contribution. 4. **Vérifier non-régression launch** - Tests ciblés application `agent/lifecycle`. - Puis `cargo test -p application agent` ou le subset existant pertinent. - Pas besoin de Vitest sauf si un texte UI est ajouté. 5. **Lot optionnel discovery** seulement après validation du MVP - Décider explicitement si un agent doit pouvoir lister les skills non assignés. - Si oui, implémenter `skill.list` / `idea_list_skills` comme nouvelle entrée orchestrateur compacte. ### Point d’attention Le fichier `ARCHITECTURE.md` contient encore des sections historiques sur un vieux plan `Builtin skill + idea CLI + inbox/outbox`, mais l’état réel du code est déjà sur `AskAgent`, `Reply`, sessions structurées, MCP bridge, mailbox/input mediator. Pour ce chantier, il faut suivre l’état réel du code et ne pas rouvrir l’ancien plan. Le bon axe est : **améliorer la conscience contextuelle des agents sur les skills existants**, pas refaire l’orchestration. +- **Prompt:** Inventaire architecture des chantiers applicatifs restant en cours après intégration locale de `agent-skill-awareness-v2`. Références mémoire: `remaining-work-idea-agent-control-ide` liste comme suites possibles: registre session/singleton agent, live-state partagé projet, handoff/canonical conversation log cross-session/cross-profile, UX conversations/délégations, MCP IdeA-only en flux réel, mise à jour mémoire/contexte automatique, restrictions profils supportés. Merci de classer ce qui est déjà livré vs encore actif, choisir le prochain chantier à reprendre en premier, et fournir un cadrage architectural initial. Ne code pas. +- **Response:** ## Inventaire post `agent-skill-awareness-v2` Contexte observé : la branche locale est `develop...origin/develop [ahead 15]`, avec seulement des fichiers runtime `.ideai/conversations/*` dirty. Je considère donc `agent-skill-awareness-v2` intégré localement et je reclasse depuis le code actuel, pas depuis la mémoire seule. ### Déjà livré / à considérer fondation acquise 1. **Registre session / singleton agent** - Livré côté application : `TerminalSessions`, `StructuredSessions`, agrégateur `LiveSessions`, `session_for_agent`, `node_for_agent`, `rebind_agent_node`. - Livré côté Tauri/UI : `list_live_agents`, `attach_live_agent`, guards frontend de lancement singleton. - Statut : **fondation livrée**, à durcir uniquement par tests de flux réel. 2. **Messagerie inter-agents / FIFO / réponse synchrone** - Livré : `AgentMailbox`, `InputMediator`, `AgentBusyChanged`, tickets, `idea_reply`, résolution par ticket, timeout/cancel. - `OrchestratorService::ask_agent` et `reply` existent, avec conversation par paire. - Statut : **livré applicativement**, UX encore perfectible. 3. **MCP IdeA-only en flux backend** - Livré : bridge `idea mcp-server`, endpoint app-tauri, serveur MCP, outils `idea_*`, runtime MCP injecté au launch, badge source `mcp/file` côté UI. - Statut : **livré côté infrastructure/app**, reste validation produit en flux réel et polish observabilité. 4. **Handoff / canonical conversation log cross-session / cross-profile** - Plus avancé que la mémoire ne le dit : `domain/src/conversation_log.rs` définit `ConversationLog`, `HandoffStore`, `HandoffSummarizer`, `ProviderSessionStore`. - Infra livrée : `FsConversationLog`, `FsHandoffStore`, `FsProviderSessionStore`, `HeuristicHandoffSummarizer`. - App livrée : `RecordTurn`, injection handoff au `LaunchAgent`, persistance provider session, séparation pair id IdeA vs engine session id. - Statut : **architecture et première implémentation livrées** ; reste qualité de résumé, couverture UX, audit de complétude de tous les chemins de record. 5. **Restrictions profils supportés** - Livré partiellement : profils structurés Claude/Codex, `structured_adapter`, `materializes_idea_bridge`, garde `guard_mcp_bridge_supported`, profils sélectionnables. - Statut : **règle technique présente**, reste formulation produit/UI des capacités et fallbacks. 6. **Agent skill awareness** - Après intégration locale : **livré comme couche de contexte**, sans nouveau store ni DTO. `agent-skills` reste L12, `awareness` reste composition de convention file. ### Encore actif / pas complètement produit 1. **UX conversations / délégations** - Backend riche, frontend encore dispersé entre agents/layout/terminal/chat/events. - Manque une lecture utilisateur claire : qui a demandé quoi, à qui, état FIFO, réponse reçue, conversation par paire, reprise. - Statut : **actif, prochain meilleur chantier**. 2. **Live-state partagé projet** - Il existe un live-state runtime : sessions, busy, mailbox, events. - Il n’existe pas encore un modèle applicatif unifié, consultable et éventuellement persistable, du “travail en cours” projet. - Statut : **partiellement livré en runtime, pas encore comme read-model produit**. 3. **Mise à jour mémoire/contexte automatique pendant la vie d’un agent** - Injection au launch : livrée. - Outils contexte/mémoire et FileGuard : présents. - Promotion automatique, signal/bruit, mise à jour continue : pas livrés. - Statut : **actif mais à repousser après UX**, car il faut d’abord rendre les fils et décisions visibles. 4. **Handoff/canonical log qualité produit** - Socle livré, mais pas encore “expérience de conversation retrouvée” garantie dans tous les cas. - Résumeur heuristique seulement ; UX de consultation/reprise à clarifier. - Statut : **fondation livrée, produit actif**. ## Prochain chantier recommandé Je recommande de reprendre en premier : **UX conversations & délégations, avec un read-model live-state minimal**. Raison : les briques backend existent maintenant. Continuer par mémoire automatique ou nouveaux mécanismes MCP risque d’empiler de l’invisible. Le prochain verrou produit est de rendre l’orchestration compréhensible et opérable : l’utilisateur doit voir ses “employés IA” travailler, attendre, déléguer, répondre et reprendre. Ce chantier peut aussi servir d’audit d’intégration : s’il manque un événement ou une donnée backend, on l’ajoute proprement comme read-model, au lieu de découvrir les trous plus tard. ## Cadrage architectural initial ### Objectif Fournir une vue produit unifiée des conversations et délégations d’un projet : - agents vivants et cellule hôte, - état `idle/busy/limited/starting` si disponible, - délégations en cours et en attente par agent, - dernière requête/réponse utile, - conversation `User↔Agent` ou `Agent↔Agent` associée, - capacité à ouvrir/rattacher la cellule concernée. Le but n’est pas encore de créer un “journal complet” frontend. Le journal canonique existe côté `.ideai/conversations`; le premier lot doit exposer un **état opérationnel scannable**. ### Frontière backend Préférer un use case de lecture applicatif plutôt que de faire recomposer le frontend depuis dix events. Nouveau read-model applicatif proposé : ```rust ProjectWorkState { live_agents: Vec, conversations: Vec, delegations: Vec, } ``` Port/domain à éviter au départ : pas de nouveau store durable tant qu’on lit les registres existants. Le read-model peut composer : - `LiveSessions` / `TerminalSessions` / `StructuredSessions`, - `InputMediator::busy_state`, - `ConversationRegistry`, - `AgentMailbox` si une méthode d’inspection propre est ajoutée, - `ConversationLog` / `HandoffStore` en lecture best-effort pour les résumés. Si inspection mailbox nécessaire, ne pas exposer l’impl `InMemoryMailbox` : ajouter un petit port ségrégué, par exemple `AgentQueueSnapshot`, ou étendre prudemment `AgentMailbox` avec une méthode read-only si l’impact reste faible. ### Frontière Tauri / DTO Ajouter une commande de lecture, pas une mutation : - `get_project_work_state(projectId) -> ProjectWorkStateDto` DTOs camelCase, stables et tolérants aux champs absents : - `LiveAgentStateDto { agentId, name, nodeId?, sessionId?, kind: "pty"|"structured", busy, limited? }` - `DelegationStateDto { ticketId, requesterAgentId?, targetAgentId, taskPreview, status: "queued"|"delivered"|"awaitingReply"|"replied"|"timedOut", source: "mcp"|"file"|"user"?, createdAtMs? }` - `ConversationThreadSummaryDto { conversationId, left, right, lastTurnPreview?, handoffPreview?, updatedAtMs? }` Ne pas exposer tout `log.jsonl` dans ce lot. Préviews seulement. ### Frontière frontend Ajouter une feature dédiée, sans mélanger avec `TerminalView` : - `frontend/src/features/workstate/` ou `features/conversations/` - hook `useProjectWorkState(projectId)` consommant un nouveau `WorkStateGateway` - panneau dans `ProjectsView` ou extension du sidebar Agents : “Work” / “Conversations” Le frontend doit continuer à consommer des ports TS, pas `invoke()` directement : - `domain/index.ts` : types miroirs DTO. - `ports/index.ts` : `WorkStateGateway`. - `adapters/workState.ts` : Tauri invoke. - mock gateway + tests Vitest. ### Ordre d’implémentation recommandé 1. **Lot A — read-model minimal sans nouvelle persistance** - Backend command `get_project_work_state` qui agrège live agents + busy state + conversations connues. - Frontend panneau simple affichant agents live/busy et dernières délégations connues. 2. **Lot B — queue/delegation snapshot propre** - Ajouter l’inspection read-only de mailbox/FIFO si le Lot A ne peut pas montrer les tickets en attente. - Tester FIFO visible : deux demandes vers le même agent apparaissent dans l’ordre. 3. **Lot C — conversation summaries depuis log/handoff** - Lire `ConversationLog::last` et `HandoffStore::load` best-effort. - Afficher preview et reprise sans charger tout le journal. 4. **Lot D — actions UX** - “Ouvrir/rattacher l’agent”, “voir la conversation”, “arrêter”, “copier résumé”, selon capacités déjà existantes. 5. **Lot E — mémoire/contexte automatique** - Seulement après visibilité des fils : proposer/persister les apprentissages utiles depuis les conversations vers mémoire/contexte via FileGuard. ### Contraintes à respecter - Ne pas faire du frontend la source de vérité du live-state. - Ne pas polluer `.ideai/memory/` avec le journal conversationnel. - Ne pas dupliquer les registres session existants. - Garder PTY brut et structured sessions substituables dans le read-model. - Toute écriture mémoire/contexte doit rester derrière les use cases/FileGuard existants. ## Synthèse Le cœur “agent control IDE” est maintenant largement livré côté backend : singleton, mailbox/FIFO, MCP IdeA-only, log/handoff/provider sessions. Le chantier prioritaire n’est plus d’inventer ces mécanismes, mais de les rendre visibles et pilotables. Je reprendrais donc par **UX conversations/délégations + read-model live-state projet minimal**, puis seulement ensuite la mise à jour automatique mémoire/contexte. \ No newline at end of file diff --git a/.ideai/conversations/7a2f446c-2efa-0c56-08dd-07cdc5cac19b/log.jsonl b/.ideai/conversations/7a2f446c-2efa-0c56-08dd-07cdc5cac19b/log.jsonl index cd5f063..c8796cb 100644 --- a/.ideai/conversations/7a2f446c-2efa-0c56-08dd-07cdc5cac19b/log.jsonl +++ b/.ideai/conversations/7a2f446c-2efa-0c56-08dd-07cdc5cac19b/log.jsonl @@ -31,3 +31,5 @@ {"id":"b835950d-2bc2-4acc-b841-98914b31d66b","conversation":"7a2f446c-2efa-0c56-08dd-07cdc5cac19b","atMs":1781939497928,"source":{"kind":"agent","agentId":"dce19c75-9669-4e45-b8de-9950025157da"},"role":"response","text":"## Cadrage `feature/agent-skill-awareness`\n\nÉtat repo constaté : `develop` est ahead origin et contient déjà L12 `agent-skills` dans le code courant (`Skill`, `SkillStore`, CRUD, assignation agent↔skill, injection des bodies dans le convention file). La branche `feature/agent-skill-awareness` diverge avant l’intégration `orchestrator-designation`; son diff est très large et mêlé à des changements runtime/anciens. Recommandation Git : **ne pas merger la branche brute**. Rejouer sélectivement les contrats utiles sur une branche neuve depuis `develop`.\n\n## 1) Objectif produit/technique\n\nObjectif produit : un agent doit savoir qu’il possède des skills assignés et comment les utiliser, sans que l’utilisateur doive le lui rappeler. Aujourd’hui L12 injecte le contenu complet des skills dans `# Skills`, mais c’est bas dans le contexte, lu comme documentation, et pas présenté comme affordance/action disponible.\n\nObjectif technique minimal : transformer l’injection “dump de contenu” en modèle “à la MCP” pour les profils MCP :\n- section haute altitude `# Skills disponibles`, juste après l’orchestration/capacités IdeA, listant les skills assignés par `name + description` ;\n- outil MCP read-only `idea_skill_read(name)` pour charger le body complet à la demande ;\n- champ optionnel `description` sur `Skill`, avec fallback déterministe via `effective_description()` ;\n- rétrocompat des anciens `skills/index.json` sans `description` ;\n- conserver un mode non-MCP compatible. Point à trancher avec Architecture : soit garder l’ancien dump complet pour `mcp == None`, soit intégrer cette découverte au futur binaire universel `idea`/skill built-in. Ne pas mélanger avec la refonte C-univ complète.\n\nLa note de branche ajoute aussi un brief inconditionnel “capacités IdeA” dans `compose_convention_file`. Attention : `ARCHITECTURE.md` récent pousse une décision plus structurante : remplacer la prose libre d’orchestration par un **skill built-in `Orchestration IdeA`** (`SkillScope::Builtin`). Donc, pour ce chantier, je recommande de **ne pas reprendre tel quel le brief inconditionnel** sauf comme correctif transitoire validé par Architecture. Le périmètre propre de `agent-skill-awareness` doit rester : “découverte et lecture des skills assignés”.\n\n## 2) Différence avec `feature/agent-skills`\n\n`agent-skills` visible dans le repo = L12, déjà intégré fonctionnellement :\n- domaine : `Skill`, `SkillScope::{Global, Project}`, `SkillRef`, `Agent.skills`/`ManifestEntry.skills` ;\n- port : `SkillStore` ;\n- infra : `FsSkillStore` global + projet ;\n- application : `CreateSkill`, `UpdateSkill`, `ListSkills`, `DeleteSkill`, `AssignSkillToAgent`, `UnassignSkillFromAgent` ;\n- backend Tauri + DTO ;\n- frontend : `features/skills`, `SkillGateway`, assignation dans `AgentsPanel` ;\n- lancement : `LaunchAgent` résout les skills assignés et injecte leurs bodies dans `compose_convention_file`.\n\n`agent-skill-awareness` = couche par-dessus L12 :\n- rend les skills visibles comme capacités nommées ;\n- évite de forcer le body complet en contexte MCP ;\n- expose une lecture explicite du body via `idea_skill_read`; \n- ajoute `description` comme méta courte, pas une nouvelle famille de skills.\n\nDonc ce n’est pas un doublon de `agent-skills`; c’est une amélioration d’ergonomie runtime. Mais son ancienne branche embarque des changements qui chevauchent des zones modifiées depuis, donc reprise manuelle.\n\n## 3) Frontières backend/frontend/docs\n\nBackend Domaine :\n- ajouter `description: Option` à `Skill` avec `#[serde(default)]` ;\n- ajouter `Skill::with_description` et `Skill::effective_description()` ;\n- préserver `with_content()` en conservant la description ;\n- éventuellement ajouter `OrchestratorCommand::ReadSkill { name, requester? }` et action `skill.read` dans `OrchestratorRequest::validate` si on garde le routage MCP via modèle orchestrator.\n\nBackend Application :\n- `CreateSkillInput` reçoit `description: Option` ;\n- `UpdateSkill` doit idéalement pouvoir modifier `description` aussi, pas seulement `content`, sinon le frontend ne peut pas éditer la méta ;\n- créer `ReadSkill` use case read-only sur le port existant `SkillStore`, pas de nouveau port ;\n- résolution par nom : project scope d’abord, global ensuite ; ambiguïté dans un même scope = erreur typée ; absent = not found ; case-insensitive.\n\nBackend Lifecycle :\n- modifier `compose_convention_file` pour les profils MCP : section `# Skills disponibles` en amont, lignes déterministes `**name** — description`, mentionnant `idea_skill_read(name=...)` ;\n- garder ordre déterministe des skills assignés selon le manifest ;\n- décider comportement non-MCP. Option conservatrice : garder le dump `# Skills` complet seulement en non-MCP pour zéro régression. Option cible architecture : passer par skill built-in + futur CLI `idea`, mais c’est un autre lot.\n\nInfrastructure / MCP :\n- ajouter `idea_skill_read` au catalogue MCP et au mapping tool → `OrchestratorCommand::ReadSkill` ;\n- dispatcher dans `OrchestratorService` vers `ReadSkill`, retour inline Markdown ;\n- câbler dans `state.rs`/composition root ;\n- mettre à jour les tests de compteur/catalogue MCP, actuellement sensibles aux nombres fixes.\n\nApp-Tauri DTO/commands :\n- `SkillDto` bénéficie du champ automatiquement si `Skill` sérialise camelCase ;\n- `CreateSkillRequestDto` et `UpdateSkillRequestDto` doivent porter `description?: string | null` ;\n- commandes UI existantes `create_skill`/`update_skill` restent les mêmes noms.\n\nFrontend :\n- `domain Skill` ajoute `description?: string | null` ;\n- `CreateSkillInput` ajoute `description?: string`; `updateSkill` doit permettre de passer description + content, pas seulement content ;\n- `SkillEditor` ajoute un champ court “Description” ; en edit, description éditable ;\n- `SkillsPanel` peut afficher description sous le nom ;\n- mocks + tests RTL à adapter.\n\nDocs :\n- `ARCHITECTURE.md` : ajouter la décision “awareness MCP” sous §14.2 ou l’aligner avec §16 si le skill built-in devient la voie cible ;\n- `agents-dev/L12-skills.md` ou note dédiée : préciser que L12 crée/assigne/injecte, et que `agent-skill-awareness` ajoute description + affordance + read tool.\n\n## 4) Contrats / ports / DTO\n\nÀ créer/modifier :\n- `domain::Skill { description: Option }` avec serde default.\n- `Skill::effective_description() -> String` : description non vide trimée, sinon première ligne non vide du body sans `#` initial.\n- `SkillStore` : **pas de nouveau port**. Les impls `list/get/save` transportent simplement le champ.\n- `FsSkillStore` index : ajouter `description` dans `IndexEntry`, `#[serde(default)]`, écriture camelCase. Le body reste dans `md/.md`.\n- `CreateSkillInput { name, description, content, scope, project_root }`.\n- `UpdateSkillInput` à faire évoluer vers `{ scope, skill_id, description, content, project_root }` ou variante patch explicite. Je conseille simple remplacement complet `description + content` pour rester aligné UI.\n- nouveau use case `ReadSkill { SkillStore }` : input `{ name, project_root }`, output `MarkdownDoc` ou DTO `{ name, scope, contentMd }` si on veut plus de traçabilité. Branche historique renvoyait seulement `MarkdownDoc`; acceptable pour MCP.\n- `OrchestratorRequest`: action/type `skill.read`, champ `name` requis.\n- `OrchestratorCommand::ReadSkill { name, requester? }`. Le `requester` est utile si la couche MCP veut garder la symétrie avec context/memory, mais le use case n’en a pas besoin.\n- MCP tool `idea_skill_read`: input `{ name: string }`, output contenu Markdown inline.\n- DTO Tauri/TS : `Skill.description?: string | null`, create/update requests.\n\nÀ ne pas créer :\n- pas de `SkillAwarenessStore` ;\n- pas de nouveau port dédié ;\n- pas de mécanisme CLI propriétaire ;\n- pas de lancement/exécution de skill depuis l’UI.\n\n## 5) Risques et ordre d’implémentation\n\nRisques :\n- la branche historique est obsolète vis-à-vis de `orchestrator-designation`; merge brut très risqué ;\n- conflit conceptuel avec la décision architecture `SkillScope::Builtin` / “Orchestration IdeA” : ne pas figer de prose libre qui sera supprimée juste après ;\n- double noms de skills : project shadow global doit être documenté ; doublons intra-scope doivent produire une erreur claire ;\n- assignation à chaud : un skill assigné pendant une session ne devient visible qu’après relaunch/régénération du convention file, sauf mécanisme futur ;\n- ancien index sans description : serde default obligatoire ;\n- tests MCP avec compteurs hardcodés fragiles ; préférer assertion par présence de tool.\n\nOrdre recommandé :\n1. **Git** : créer une branche neuve depuis `develop`, par exemple `feature/agent-skill-awareness-v2`; ne cherry-pick que si les hunks sont triviaux, sinon réimplémenter depuis la note. Garder `feature/agent-skill-awareness` comme référence de design/test, pas comme base de merge.\n2. **DevBackend T1** : domaine + serde + tests purs (`description`, fallback, `with_content` conserve description, legacy JSON).\n3. **DevBackend T2** : `FsSkillStore`, use cases create/update/list, DTO Tauri. Tests store legacy + roundtrip.\n4. **DevBackend T3** : `ReadSkill` + `OrchestratorCommand::ReadSkill` + validation `skill.read`. Tests résolution project/global/ambiguous/not found.\n5. **DevBackend T4** : MCP catalogue/mapping/service/state. Tests tool map + dispatch + catalogue par nom.\n6. **DevBackend T5** : `compose_convention_file` awareness. Tests : MCP avec skills affiche `# Skills disponibles`, descriptions, appel `idea_skill_read`, pas de body complet si décision retenue ; non-MCP conserve baseline/dump complet ; zéro skill omet la section ; ordre avant persona ou juste après orchestration selon décision.\n7. **DevFrontend T6** : champ description dans domain/ports/adapters/mock/SkillEditor/SkillsPanel/tests. Ne pas toucher à l’exécution de skills.\n8. **Docs T7** : architecture + agents-dev, en explicitant la frontière avec futur `SkillScope::Builtin`.\n9. **QA T8** : `cargo test --workspace`, `pnpm test`, puis e2e AppImage : agent neuf + skill assigné + profil MCP voit `# Skills disponibles`, appelle `idea_skill_read`, reçoit le body ; profil non-MCP ne régresse pas.\n\nVerdict court : `agent-skills` = socle déjà intégré ; `agent-skill-awareness` = affordance + lecture à la demande. Reprendre le chantier, oui, mais en branche neuve depuis `develop`, avec périmètre serré et sans avaler le vieux diff."} {"id":"ce6b9e0a-cbd7-4790-b155-dbecf635e06e","conversation":"7a2f446c-2efa-0c56-08dd-07cdc5cac19b","atMs":1781945112212,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Reprise chantier `feature/agent-skill-awareness-v2` après hotfix livraison délégation/logs submit. Contexte: branche actuelle `feature/agent-skill-awareness-v2`; dirty attendu avec fichiers runtime `.ideai/*` et changements code du hotfix listés dans la mémoire `checkpoint-delivery-submit-logging-fix`. Le checkpoint précédent disait de cadrer `agent-skill-awareness` vs `agent-skills` avant implémentation. Merci de fournir le cadrage architecture: objectif exact, frontières backend/frontend, contrats/DTO/ports à toucher, et ordre d'implémentation recommandé. Ne code pas."} {"id":"506b5f0c-e7c2-457e-81cf-a22d5ac5ac97","conversation":"7a2f446c-2efa-0c56-08dd-07cdc5cac19b","atMs":1781945248445,"source":{"kind":"agent","agentId":"dce19c75-9669-4e45-b8de-9950025157da"},"role":"response","text":"## Cadrage architecture — `feature/agent-skill-awareness-v2`\n\n### Verdict de cadrage\n\nIl faut distinguer strictement deux sujets :\n\n- **`agent-skills` / L12** = fonctionnalité déjà existante : entité `Skill`, scopes `Global|Project`, CRUD, assignation agent↔skill dans le manifeste, injection des bodies assignés dans le convention file à l’activation.\n- **`agent-skill-awareness`** = rendre l’agent conscient du système de skills IdeA et de la manière correcte de les utiliser/contribuer, sans réimplémenter L12.\n\nDonc le chantier recommandé n’est pas un nouveau store, ni une nouvelle UI CRUD, ni un mécanisme de slash-commands fournisseur. C’est une évolution de **composition de contexte agent** + éventuellement une petite surface de découverte orchestrateur, gardée séparée.\n\n### Objectif exact\n\nMVP recommandé : à chaque activation d’agent, le convention file doit expliquer explicitement :\n\n1. Les sections sous `# Skills` sont les workflows assignés à cet agent, utilisables quand pertinents.\n2. Un skill assigné est du contexte opérationnel, pas une commande magique ni une sous-tâche fournisseur.\n3. Si l’agent identifie un workflow réutilisable, il doit passer par l’orchestration IdeA (`idea_create_skill` côté MCP, ou `skill.create` côté protocole fichier), jamais écrire directement dans `.ideai/skills/`.\n4. Les skills non assignés ne doivent pas être injectés intégralement à tous les agents : l’assignation reste la frontière de contexte.\n\nCe MVP ferme le flou `awareness` vs `skills` : on garde L12 comme source métier, on améliore la compréhension de l’agent au moment où son contexte est généré.\n\n### Frontières backend\n\nÀ toucher :\n\n- `crates/application/src/agent/lifecycle.rs`\n - `compose_convention_file(...)` est le point naturel : fonction pure, déjà responsable de `Project root`, orchestration, contexte projet, persona, skills, mémoire, handoff.\n - Ajouter une sous-section courte, stable et testable, par exemple dans `# Orchestration IdeA` ou juste avant `# Skills` : `## Usage des skills IdeA`.\n - Garder l’ordre actuel : project root → orchestration/awareness → contexte projet → persona → skills → mémoire → handoff.\n\n- Tests application de composition dans le même fichier ou suite existante :\n - agent sans skills : la consigne awareness peut exister, mais pas de section `# Skills` si la liste est vide, pour préserver le contrat actuel.\n - agent avec skills : la consigne précède les bodies et les bodies restent en ordre manifeste.\n - `mcp_enabled=true` : mentionner les outils `idea_create_skill` / outils natifs IdeA.\n - `mcp_enabled=false` : mentionner le protocole fichier `skill.create`.\n\nÀ ne pas toucher pour le MVP :\n\n- Pas de nouveau `SkillStore`.\n- Pas de nouveau port domaine.\n- Pas de nouveau DTO Tauri.\n- Pas de mutation du manifeste.\n- Pas de changement des invariants `Skill`, `SkillRef`, `Agent.skills`.\n- Pas de scope `Builtin` tant que le projet reste sur l’état réel actuel : l’architecture historique en parle, mais le code courant a déjà une prose d’orchestration dynamique et le pivot structuré/MCP est livré différemment. Réintroduire `Builtin` serait un autre chantier.\n\n### Frontières frontend\n\nMVP : **aucune frontière frontend obligatoire**.\n\nL’UI skills existe déjà via :\n\n- `frontend/src/domain/index.ts` : `Skill`, `SkillRef`, `SkillScope`.\n- `frontend/src/ports/index.ts` : `SkillGateway`.\n- `frontend/src/adapters/skill.ts` : `list/create/update/delete/assign/unassign`.\n- `frontend/src/features/skills/*` : panneau et view-model L12.\n\nÉventuel ajustement UI, à garder non bloquant : afficher dans le panneau skills une phrase sobre du type “Les skills assignés sont injectés au lancement de l’agent”. Pas de nouveau gateway pour ça.\n\n### Contrats/DTO/ports à toucher\n\nMVP recommandé :\n\n- **Domaine Rust** : aucun nouveau type requis.\n- **Ports Rust** : aucun nouveau port.\n- **Application** : seulement la fonction pure de composition du convention file et ses tests.\n- **Infrastructure** : aucun changement.\n- **Tauri DTO/commands** : aucun changement.\n- **Frontend DTO/ports** : aucun changement.\n\nContrats existants à respecter :\n\n- `domain::Skill { id, name, content_md, scope }`.\n- `domain::SkillRef { skill_id, scope }` stocké sur l’agent/manifeste.\n- `SkillStore::list/get/save/delete` reste la seule abstraction de persistance.\n- `LaunchAgent::resolve_skills` reste best-effort pour les dangling refs : un skill supprimé ne bloque pas le launch.\n- `compose_convention_file` reste pure/I-O free.\n\n### Option séparée : découverte typée des skills par agent\n\nÀ ne faire que si le produit veut que les agents découvrent les skills non assignés.\n\nDans ce cas, ne pas injecter tous les bodies. Ajouter plutôt une surface compacte :\n\n- `OrchestratorCommand::ListSkills { scope: Option }` ou `ListSkills` avec scope requis.\n- Alias protocole : `skill.list`.\n- Outil MCP : `idea_list_skills(scope?)`.\n- `OrchestratorService` réutilise le `SkillStore` existant et renvoie une liste compacte `{ id, name, scope }`, pas `contentMd` par défaut.\n\nCe serait un lot séparé, parce que cela touche `domain/src/orchestrator.rs`, `application/src/orchestrator/service.rs`, l’adapter MCP / watcher, et éventuellement les DTO de réponse. Ce n’est pas nécessaire pour corriger l’awareness des skills assignés.\n\n### Ordre d’implémentation recommandé\n\n1. **Stabiliser le texte de contrat**\n - Rédiger une section courte “Usage des skills IdeA”.\n - Deux variantes : MCP (`idea_create_skill`) et fichier (`skill.create`).\n - Garder l’interdiction des subagents natifs dans la section orchestration existante.\n\n2. **Modifier `compose_convention_file` uniquement**\n - Ajouter un helper pur si utile, par exemple `compose_skill_awareness(mcp_enabled: bool) -> &'static str`.\n - Ne pas déplacer la section `# Skills` ni changer la forme des bodies.\n\n3. **Ajouter les tests de composition**\n - No-skills : pas de `# Skills`, awareness présente.\n - With-skills : awareness + bodies dans l’ordre.\n - MCP vs file : bonne consigne de création/contribution.\n\n4. **Vérifier non-régression launch**\n - Tests ciblés application `agent/lifecycle`.\n - Puis `cargo test -p application agent` ou le subset existant pertinent.\n - Pas besoin de Vitest sauf si un texte UI est ajouté.\n\n5. **Lot optionnel discovery** seulement après validation du MVP\n - Décider explicitement si un agent doit pouvoir lister les skills non assignés.\n - Si oui, implémenter `skill.list` / `idea_list_skills` comme nouvelle entrée orchestrateur compacte.\n\n### Point d’attention\n\nLe fichier `ARCHITECTURE.md` contient encore des sections historiques sur un vieux plan `Builtin skill + idea CLI + inbox/outbox`, mais l’état réel du code est déjà sur `AskAgent`, `Reply`, sessions structurées, MCP bridge, mailbox/input mediator. Pour ce chantier, il faut suivre l’état réel du code et ne pas rouvrir l’ancien plan. Le bon axe est : **améliorer la conscience contextuelle des agents sur les skills existants**, pas refaire l’orchestration."} +{"id":"e9585470-e1d2-45e9-b0ed-aec238056190","conversation":"7a2f446c-2efa-0c56-08dd-07cdc5cac19b","atMs":1781946373184,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Inventaire architecture des chantiers applicatifs restant en cours après intégration locale de `agent-skill-awareness-v2`. Références mémoire: `remaining-work-idea-agent-control-ide` liste comme suites possibles: registre session/singleton agent, live-state partagé projet, handoff/canonical conversation log cross-session/cross-profile, UX conversations/délégations, MCP IdeA-only en flux réel, mise à jour mémoire/contexte automatique, restrictions profils supportés. Merci de classer ce qui est déjà livré vs encore actif, choisir le prochain chantier à reprendre en premier, et fournir un cadrage architectural initial. Ne code pas."} +{"id":"9dc7772c-d574-470e-a792-56a71d4a85cc","conversation":"7a2f446c-2efa-0c56-08dd-07cdc5cac19b","atMs":1781946451575,"source":{"kind":"agent","agentId":"dce19c75-9669-4e45-b8de-9950025157da"},"role":"response","text":"## Inventaire post `agent-skill-awareness-v2`\n\nContexte observé : la branche locale est `develop...origin/develop [ahead 15]`, avec seulement des fichiers runtime `.ideai/conversations/*` dirty. Je considère donc `agent-skill-awareness-v2` intégré localement et je reclasse depuis le code actuel, pas depuis la mémoire seule.\n\n### Déjà livré / à considérer fondation acquise\n\n1. **Registre session / singleton agent**\n - Livré côté application : `TerminalSessions`, `StructuredSessions`, agrégateur `LiveSessions`, `session_for_agent`, `node_for_agent`, `rebind_agent_node`.\n - Livré côté Tauri/UI : `list_live_agents`, `attach_live_agent`, guards frontend de lancement singleton.\n - Statut : **fondation livrée**, à durcir uniquement par tests de flux réel.\n\n2. **Messagerie inter-agents / FIFO / réponse synchrone**\n - Livré : `AgentMailbox`, `InputMediator`, `AgentBusyChanged`, tickets, `idea_reply`, résolution par ticket, timeout/cancel.\n - `OrchestratorService::ask_agent` et `reply` existent, avec conversation par paire.\n - Statut : **livré applicativement**, UX encore perfectible.\n\n3. **MCP IdeA-only en flux backend**\n - Livré : bridge `idea mcp-server`, endpoint app-tauri, serveur MCP, outils `idea_*`, runtime MCP injecté au launch, badge source `mcp/file` côté UI.\n - Statut : **livré côté infrastructure/app**, reste validation produit en flux réel et polish observabilité.\n\n4. **Handoff / canonical conversation log cross-session / cross-profile**\n - Plus avancé que la mémoire ne le dit : `domain/src/conversation_log.rs` définit `ConversationLog`, `HandoffStore`, `HandoffSummarizer`, `ProviderSessionStore`.\n - Infra livrée : `FsConversationLog`, `FsHandoffStore`, `FsProviderSessionStore`, `HeuristicHandoffSummarizer`.\n - App livrée : `RecordTurn`, injection handoff au `LaunchAgent`, persistance provider session, séparation pair id IdeA vs engine session id.\n - Statut : **architecture et première implémentation livrées** ; reste qualité de résumé, couverture UX, audit de complétude de tous les chemins de record.\n\n5. **Restrictions profils supportés**\n - Livré partiellement : profils structurés Claude/Codex, `structured_adapter`, `materializes_idea_bridge`, garde `guard_mcp_bridge_supported`, profils sélectionnables.\n - Statut : **règle technique présente**, reste formulation produit/UI des capacités et fallbacks.\n\n6. **Agent skill awareness**\n - Après intégration locale : **livré comme couche de contexte**, sans nouveau store ni DTO. `agent-skills` reste L12, `awareness` reste composition de convention file.\n\n### Encore actif / pas complètement produit\n\n1. **UX conversations / délégations**\n - Backend riche, frontend encore dispersé entre agents/layout/terminal/chat/events.\n - Manque une lecture utilisateur claire : qui a demandé quoi, à qui, état FIFO, réponse reçue, conversation par paire, reprise.\n - Statut : **actif, prochain meilleur chantier**.\n\n2. **Live-state partagé projet**\n - Il existe un live-state runtime : sessions, busy, mailbox, events.\n - Il n’existe pas encore un modèle applicatif unifié, consultable et éventuellement persistable, du “travail en cours” projet.\n - Statut : **partiellement livré en runtime, pas encore comme read-model produit**.\n\n3. **Mise à jour mémoire/contexte automatique pendant la vie d’un agent**\n - Injection au launch : livrée.\n - Outils contexte/mémoire et FileGuard : présents.\n - Promotion automatique, signal/bruit, mise à jour continue : pas livrés.\n - Statut : **actif mais à repousser après UX**, car il faut d’abord rendre les fils et décisions visibles.\n\n4. **Handoff/canonical log qualité produit**\n - Socle livré, mais pas encore “expérience de conversation retrouvée” garantie dans tous les cas.\n - Résumeur heuristique seulement ; UX de consultation/reprise à clarifier.\n - Statut : **fondation livrée, produit actif**.\n\n## Prochain chantier recommandé\n\nJe recommande de reprendre en premier : **UX conversations & délégations, avec un read-model live-state minimal**.\n\nRaison : les briques backend existent maintenant. Continuer par mémoire automatique ou nouveaux mécanismes MCP risque d’empiler de l’invisible. Le prochain verrou produit est de rendre l’orchestration compréhensible et opérable : l’utilisateur doit voir ses “employés IA” travailler, attendre, déléguer, répondre et reprendre.\n\nCe chantier peut aussi servir d’audit d’intégration : s’il manque un événement ou une donnée backend, on l’ajoute proprement comme read-model, au lieu de découvrir les trous plus tard.\n\n## Cadrage architectural initial\n\n### Objectif\n\nFournir une vue produit unifiée des conversations et délégations d’un projet :\n\n- agents vivants et cellule hôte,\n- état `idle/busy/limited/starting` si disponible,\n- délégations en cours et en attente par agent,\n- dernière requête/réponse utile,\n- conversation `User↔Agent` ou `Agent↔Agent` associée,\n- capacité à ouvrir/rattacher la cellule concernée.\n\nLe but n’est pas encore de créer un “journal complet” frontend. Le journal canonique existe côté `.ideai/conversations`; le premier lot doit exposer un **état opérationnel scannable**.\n\n### Frontière backend\n\nPréférer un use case de lecture applicatif plutôt que de faire recomposer le frontend depuis dix events.\n\nNouveau read-model applicatif proposé :\n\n```rust\nProjectWorkState {\n live_agents: Vec,\n conversations: Vec,\n delegations: Vec,\n}\n```\n\nPort/domain à éviter au départ : pas de nouveau store durable tant qu’on lit les registres existants. Le read-model peut composer :\n\n- `LiveSessions` / `TerminalSessions` / `StructuredSessions`,\n- `InputMediator::busy_state`,\n- `ConversationRegistry`,\n- `AgentMailbox` si une méthode d’inspection propre est ajoutée,\n- `ConversationLog` / `HandoffStore` en lecture best-effort pour les résumés.\n\nSi inspection mailbox nécessaire, ne pas exposer l’impl `InMemoryMailbox` : ajouter un petit port ségrégué, par exemple `AgentQueueSnapshot`, ou étendre prudemment `AgentMailbox` avec une méthode read-only si l’impact reste faible.\n\n### Frontière Tauri / DTO\n\nAjouter une commande de lecture, pas une mutation :\n\n- `get_project_work_state(projectId) -> ProjectWorkStateDto`\n\nDTOs camelCase, stables et tolérants aux champs absents :\n\n- `LiveAgentStateDto { agentId, name, nodeId?, sessionId?, kind: \"pty\"|\"structured\", busy, limited? }`\n- `DelegationStateDto { ticketId, requesterAgentId?, targetAgentId, taskPreview, status: \"queued\"|\"delivered\"|\"awaitingReply\"|\"replied\"|\"timedOut\", source: \"mcp\"|\"file\"|\"user\"?, createdAtMs? }`\n- `ConversationThreadSummaryDto { conversationId, left, right, lastTurnPreview?, handoffPreview?, updatedAtMs? }`\n\nNe pas exposer tout `log.jsonl` dans ce lot. Préviews seulement.\n\n### Frontière frontend\n\nAjouter une feature dédiée, sans mélanger avec `TerminalView` :\n\n- `frontend/src/features/workstate/` ou `features/conversations/`\n- hook `useProjectWorkState(projectId)` consommant un nouveau `WorkStateGateway`\n- panneau dans `ProjectsView` ou extension du sidebar Agents : “Work” / “Conversations”\n\nLe frontend doit continuer à consommer des ports TS, pas `invoke()` directement :\n\n- `domain/index.ts` : types miroirs DTO.\n- `ports/index.ts` : `WorkStateGateway`.\n- `adapters/workState.ts` : Tauri invoke.\n- mock gateway + tests Vitest.\n\n### Ordre d’implémentation recommandé\n\n1. **Lot A — read-model minimal sans nouvelle persistance**\n - Backend command `get_project_work_state` qui agrège live agents + busy state + conversations connues.\n - Frontend panneau simple affichant agents live/busy et dernières délégations connues.\n\n2. **Lot B — queue/delegation snapshot propre**\n - Ajouter l’inspection read-only de mailbox/FIFO si le Lot A ne peut pas montrer les tickets en attente.\n - Tester FIFO visible : deux demandes vers le même agent apparaissent dans l’ordre.\n\n3. **Lot C — conversation summaries depuis log/handoff**\n - Lire `ConversationLog::last` et `HandoffStore::load` best-effort.\n - Afficher preview et reprise sans charger tout le journal.\n\n4. **Lot D — actions UX**\n - “Ouvrir/rattacher l’agent”, “voir la conversation”, “arrêter”, “copier résumé”, selon capacités déjà existantes.\n\n5. **Lot E — mémoire/contexte automatique**\n - Seulement après visibilité des fils : proposer/persister les apprentissages utiles depuis les conversations vers mémoire/contexte via FileGuard.\n\n### Contraintes à respecter\n\n- Ne pas faire du frontend la source de vérité du live-state.\n- Ne pas polluer `.ideai/memory/` avec le journal conversationnel.\n- Ne pas dupliquer les registres session existants.\n- Garder PTY brut et structured sessions substituables dans le read-model.\n- Toute écriture mémoire/contexte doit rester derrière les use cases/FileGuard existants.\n\n## Synthèse\n\nLe cœur “agent control IDE” est maintenant largement livré côté backend : singleton, mailbox/FIFO, MCP IdeA-only, log/handoff/provider sessions. Le chantier prioritaire n’est plus d’inventer ces mécanismes, mais de les rendre visibles et pilotables. Je reprendrais donc par **UX conversations/délégations + read-model live-state projet minimal**, puis seulement ensuite la mise à jour automatique mémoire/contexte."}