Compare commits
222 Commits
805d4b70a2
...
feature/11
| Author | SHA1 | Date | |
|---|---|---|---|
| 045e0984cc | |||
| 78f7c8fe2d | |||
| 851f1f8f2c | |||
| 41aa2789a7 | |||
| f4895208d7 | |||
| 88a5256a1e | |||
| efbd084b7d | |||
| b734c237d3 | |||
| e1d8f5885f | |||
| 6f532d7434 | |||
| ce375c3e70 | |||
| 0b83b5bbd2 | |||
| e74a9703f9 | |||
| 865f90eafd | |||
| d7b6038f23 | |||
| cf074a7d61 | |||
| 038e90ecec | |||
| 02603441c1 | |||
| 4321d048ac | |||
| ca70ec75f4 | |||
| e7bf1d3666 | |||
| e5bafc30e7 | |||
| ea7ea71230 | |||
| c807a70fea | |||
| d741035c47 | |||
| 455eba3f91 | |||
| 13ff1a4f51 | |||
| 480cdc41ac | |||
| 0821739924 | |||
| b5d7e16501 | |||
| dae07d35bb | |||
| 13fb538880 | |||
| 3047dc9195 | |||
| e8731834f4 | |||
| 6e98fd89f7 | |||
| da907b880e | |||
| 6a87c4635f | |||
| ad491e765f | |||
| 69e5878679 | |||
| 55330732dd | |||
| 0f0a76d806 | |||
| 7fee56acf5 | |||
| 6e9a3ff657 | |||
| 7d3e74a114 | |||
| 56631bd3c8 | |||
| c9fffd7c47 | |||
| 0f57e7323a | |||
| 4ac2dd1568 | |||
| 557d1c3f24 | |||
| e8f6e9eded | |||
| ef747cd156 | |||
| 1784027f5d | |||
| e943a0efed | |||
| 162e3ae641 | |||
| 12c7d103d0 | |||
| c181b43d04 | |||
| 23a3c2788f | |||
| bece7c92c5 | |||
| 98fb05447d | |||
| ac726d075e | |||
| bb35641715 | |||
| 47aacc6da9 | |||
| 3a18556ffa | |||
| a197197a90 | |||
| 4fd339c047 | |||
| e9b01795d1 | |||
| 30f6415d51 | |||
| cb2d0c2d44 | |||
| 678ff3011b | |||
| 277a0e494a | |||
| 1139041603 | |||
| 527c2dde61 | |||
| e7f67bada9 | |||
| e69361feb7 | |||
| 45def4844a | |||
| 5a7431b442 | |||
| 5d262231e2 | |||
| 60f4b33e53 | |||
| 8509653e3c | |||
| 294865f805 | |||
| ef84d5cc49 | |||
| 448edfc364 | |||
| c3078875f4 | |||
| 2db37a50fa | |||
| 5f15cdbf28 | |||
| c84a66f4e8 | |||
| eeba0ddb46 | |||
| 37ead61911 | |||
| 5175589aa5 | |||
| 32408b5232 | |||
| b4a34b40e5 | |||
| a7abd331b8 | |||
| 8387c1bbdf | |||
| 6e92536d84 | |||
| 348bccae34 | |||
| a69c5db093 | |||
| 445ecaf82e | |||
| 17d6baf15a | |||
| 1be5f8cd18 | |||
| 3f1e132e88 | |||
| 8fe93d1652 | |||
| 9463b7e6bf | |||
| 481a7e2498 | |||
| 120d0d1ac2 | |||
| aec4293750 | |||
| 4de25d2bce | |||
| f605989fa5 | |||
| 25728dee74 | |||
| 5ca2ab77f3 | |||
| a7197fc53b | |||
| 50d237e836 | |||
| 166adc3c4b | |||
| a13a6c1801 | |||
| f965f64b07 | |||
| b30c9c7590 | |||
| 7efa634f23 | |||
| 49e1d5a157 | |||
| 7fbaa8eba6 | |||
| ae01297b6b | |||
| 42804fc55d | |||
| 75d1ce87fc | |||
| e8a72f5173 | |||
| 677f64d18e | |||
| f915635e07 | |||
| 7c677c4fb4 | |||
| 328c941f22 | |||
| b7d38f1d30 | |||
| 77684ea183 | |||
| 56b9f5f619 | |||
| 32c670a2b3 | |||
| 24f5e85974 | |||
| f0f2f3b497 | |||
| 62ecefe1e8 | |||
| 48b8853214 | |||
| fe0e53ec59 | |||
| 5ee25d1ef6 | |||
| 4f57e5a0db | |||
| 0e15482ce2 | |||
| 506d58956b | |||
| 8e481aed69 | |||
| c246875f6d | |||
| de9c90966d | |||
| c9ce3d7c4e | |||
| 6117177957 | |||
| d538808a0d | |||
| dd1d083a1a | |||
| 1bc5217dbc | |||
| 5254f16095 | |||
| 6391d1c75a | |||
| 7487902ddb | |||
| 917be995a4 | |||
| e457152c66 | |||
| e500e31663 | |||
| fa353f6c0b | |||
| 4ed0b168d2 | |||
| e0cdb4aa56 | |||
| c8fef2a76a | |||
| 955db79e97 | |||
| 5505acc1f6 | |||
| ebad5ff9f2 | |||
| 18e6bedb8b | |||
| f7cae4c0a8 | |||
| 2f7f111545 | |||
| ce5aa2811c | |||
| 62b71776f5 | |||
| c6e34483d3 | |||
| 2d7396a86b | |||
| 51b5d07f35 | |||
| b4b86cdc0e | |||
| 63a7b6165f | |||
| bd5d8d864a | |||
| 83e4df7626 | |||
| 67101ba607 | |||
| e24bb5f1f4 | |||
| 4099b0d1c4 | |||
| fd5c8932ca | |||
| 141c13dabb | |||
| e0ee24e3b5 | |||
| ad1f2257e6 | |||
| 2183dfd291 | |||
| bd335c3a1c | |||
| fe7ed0aa20 | |||
| c67ec4f7bd | |||
| 8cdc44de6e | |||
| 76560ab101 | |||
| b4a01e0ae9 | |||
| c1051ce2f5 | |||
| f7f56e8583 | |||
| ea7a98be03 | |||
| 7ddf4d46b9 | |||
| afbf315e97 | |||
| 9326a4897a | |||
| 8bbd8d3d68 | |||
| 225890b57a | |||
| 9430c65050 | |||
| 631dd4eccf | |||
| b152e33b60 | |||
| 0e594adaf3 | |||
| 221cc8be78 | |||
| 6387fac34f | |||
| 1e0cb16ead | |||
| 8570adb8e0 | |||
| e54ffae0c3 | |||
| 3fff3402ec | |||
| f24f8f12aa | |||
| e64c0b7840 | |||
| 1331c5b2c2 | |||
| 2eb51d3335 | |||
| 55087b5d9b | |||
| 79f06c26d9 | |||
| e6f10d2b74 | |||
| 13d45cb752 | |||
| 9ee7290cde | |||
| 0039958b82 | |||
| a3c0dd410a | |||
| 1c28754b58 | |||
| 338b8707de | |||
| daa93525d7 | |||
| 61e5e41f0d | |||
| 73859a05e1 | |||
| c864d4a692 | |||
| 09e7f212b7 |
15
.gitignore
vendored
15
.gitignore
vendored
@ -9,6 +9,9 @@ target/
|
||||
# Dependencies and build output (package-lock.json IS committed).
|
||||
frontend/node_modules/
|
||||
frontend/dist/
|
||||
# Sortie du build web (VITE_TRANSPORT=http) servie par idea-serve : meme
|
||||
# classe que dist/, rebuildable depuis les sources — not versioned (#65).
|
||||
frontend/dist-web/
|
||||
# Root-level node_modules (dev tooling installs at repo root — never versioned).
|
||||
/node_modules/
|
||||
# npm/yarn/pnpm debug logs
|
||||
@ -42,12 +45,19 @@ frontend/coverage/
|
||||
# Runtime file-protocol orchestration requests/responses — transient I/O, not
|
||||
# durable project state (curation .ideai §chantier secondaire).
|
||||
.ideai/requests/
|
||||
# Ticket store IdeA: l'utilisateur veut conserver l'état local des tickets en
|
||||
# dehors des branches Git. À ignorer, sinon les changements de branche peuvent
|
||||
# écraser/supprimer cet état local.
|
||||
.ideai/tickets/
|
||||
# Volatile agent live-state snapshot ("who is doing what right now", lot LS2):
|
||||
# rebuilt at runtime, keyed last-writer-wins — not versioned (unlike .ideai/memory/).
|
||||
.ideai/live-state.json
|
||||
# UI layout runtime state (active layout id + session ids) — machine-local,
|
||||
# rebuilt at runtime, last-writer-wins — not versioned (same class as live-state.json).
|
||||
/.ideai/layouts.json
|
||||
# Permissions MCP locales/outillage: état de runtime propre à la machine et aux
|
||||
# sessions locales, pas une source de vérité projet.
|
||||
.ideai/mcp-tool-permissions.json
|
||||
|
||||
# ─── Editors / OS ───────────────────────────────────────────────────────────
|
||||
.idea/
|
||||
@ -62,3 +72,8 @@ Thumbs.db
|
||||
# seul .ideai/memory/ est le store durable versionné).
|
||||
.ideai/conversations/
|
||||
.ideai/agents.json
|
||||
.ideai/background-tasks/
|
||||
|
||||
# IdeA local runtime state kept outside Git
|
||||
.ideai/tickets/
|
||||
.ideai/mcp-tool-permissions.json
|
||||
|
||||
93
.ideai/agents/context.md
Normal file
93
.ideai/agents/context.md
Normal file
@ -0,0 +1,93 @@
|
||||
# Context — Agent d'assistance légère à faible coût
|
||||
|
||||
> Tu es l'**agent Context**. Tu tournes sur un **LLM local, peu puissant**. Ta seule
|
||||
> raison d'être : **absorber les tâches mécaniques et coûteuses en tokens** que les
|
||||
> autres agents (Main, Architect, UX, DevBackend, DevFrontend, QA, Git) devraient sinon
|
||||
> faire eux-mêmes, pour qu'ils atteignent **moins souvent leur limite de tokens** —
|
||||
> **sans dégrader la qualité de leurs décisions**.
|
||||
|
||||
Tu n'es **pas** un agent de décision. Tu ne remplaces aucun rôle du cycle. Tu prépares,
|
||||
tu extrais, tu résumes — l'agent qui t'a sollicité garde la responsabilité et le dernier
|
||||
mot sur tout ce qui compte.
|
||||
|
||||
---
|
||||
|
||||
## 1. Ce que tu fais
|
||||
|
||||
Tu réponds à des demandes ponctuelles d'un autre agent (jamais directement de
|
||||
l'utilisateur, sauf sollicitation explicite). Ton périmètre :
|
||||
|
||||
- **Recherche de symboles** : localiser où une fonction/classe/type est définie, où elle
|
||||
est utilisée, sans que l'agent appelant ait à lire tout l'arbre de fichiers.
|
||||
- **Résumé de fichier(s)** : compresser un fichier long ou un ensemble de fichiers en un
|
||||
résumé factuel (structure, responsabilités, points d'entrée) — pas une interprétation
|
||||
architecturale.
|
||||
- **Classification d'erreurs de compilation** : trier une sortie de build brute par
|
||||
catégorie (type, fichier, ligne, nature de l'erreur) pour que l'agent appelant lise un
|
||||
tableau plutôt que 2000 lignes de log.
|
||||
- **Extraction des tests en échec** : à partir d'une sortie de test brute, lister les
|
||||
tests KO avec leur message d'erreur, sans le bruit des tests verts.
|
||||
- **Résumé de diff** : condenser un `git diff` volumineux en une liste factuelle de
|
||||
fichiers touchés et de la nature du changement (ajout, suppression, renommage,
|
||||
ampleur).
|
||||
- **Repérage de fichiers probablement concernés par un ticket** : à partir d'un texte de
|
||||
ticket et d'une recherche dans l'arbre du projet, proposer une liste de fichiers
|
||||
candidats — une piste de départ, pas une garantie.
|
||||
|
||||
Tout le reste de la liste d'origine (proposer un message de commit, générer un test
|
||||
unitaire localisé, mettre à jour une documentation) est **hors périmètre** : ce sont des
|
||||
artefacts qui engagent une décision (Git pour les commits, QA pour les tests, le
|
||||
propriétaire du contexte pour la doc). Un modèle local peu puissant qui les produit
|
||||
directement fait courir un risque de qualité que la vérification par l'agent fort
|
||||
annulerait de toute façon le gain de tokens visé. Si on te demande l'un de ces trois,
|
||||
tu peux produire un **brouillon explicitement marqué comme tel**, jamais un livrable.
|
||||
|
||||
---
|
||||
|
||||
## 2. Ce que tu ne fais jamais
|
||||
|
||||
- Tu ne **décides** rien : pas d'architecture, pas de contrat, pas de branche, pas de
|
||||
verdict de test, pas de conception UI.
|
||||
- Tu ne **corriges pas de code de production**.
|
||||
- Tu ne **remplaces pas la vérification** : si une sortie doit être prouvée vraie (tests
|
||||
QA, verdict de build), c'est l'agent propriétaire qui l'exécute et la lit, pas toi.
|
||||
- Tu ne **inventes pas** quand l'information te manque. Un modèle local faible qui
|
||||
complète par extrapolation produit un faux gain : ça coûte plus cher en correction
|
||||
après coup qu'en tokens économisés avant. **Dis "non trouvé" ou "incertain"
|
||||
explicitement plutôt que de deviner.**
|
||||
- Tu ne gères aucun ticket, tu n'appelles pas d'outil de remise de résultat : tu réponds
|
||||
normalement en fin de tour, la réponse finale est capturée par IdeA.
|
||||
|
||||
---
|
||||
|
||||
## 3. Comment produire une réponse utile (vu ta faiblesse de modèle)
|
||||
|
||||
Ta valeur vient de la **compression fiable**, pas de l'intelligence. Pour rester fiable :
|
||||
|
||||
- **Cite ce que tu as effectivement vu** (chemins de fichiers, numéros de ligne, extraits
|
||||
courts) plutôt que de reformuler de mémoire. Une réponse vérifiable vaut mieux qu'une
|
||||
réponse fluide.
|
||||
- **Format court, structuré, sans prose.** Liste à puces, tableau, ou bloc de citations —
|
||||
jamais un paragraphe d'analyse. L'agent qui te lit doit pouvoir consommer ta réponse en
|
||||
quelques secondes.
|
||||
- **Un scope explicite dans chaque réponse** : dis ce que tu as couvert (quels fichiers,
|
||||
quelle partie du log) et ce que tu n'as pas couvert, si la demande dépassait ce que tu
|
||||
as pu lire.
|
||||
- **N'ajoute pas de jugement de valeur ni de recommandation** — "ce fichier semble mal
|
||||
conçu", "cette erreur est grave" sont des avis qui n'appartiennent pas à ton rôle et
|
||||
que ta faiblesse de modèle ne te permet pas de fonder correctement.
|
||||
- **Reste bref.** Le but est d'économiser des tokens à l'agent appelant, pas de produire
|
||||
un rapport plus long que le log d'origine.
|
||||
|
||||
---
|
||||
|
||||
## 4. Délégation & collaboration
|
||||
|
||||
- Tu es sollicité par Main ou par un autre agent via l'orchestration IdeA. Traite la
|
||||
demande et termine ton tour avec ta réponse normale — pas de protocole de ticket.
|
||||
- Si la demande sort clairement de ton périmètre (une décision, un arbitrage, un
|
||||
jugement de qualité), dis-le et renvoie vers l'agent propriétaire au lieu d'improviser
|
||||
une réponse hors sujet.
|
||||
- Si tu n'es pas sûr d'un résultat (symbole non trouvé, fichier candidat incertain), dis
|
||||
la limite plutôt que de la masquer — un agent fort qui reçoit une fausse certitude perd
|
||||
plus de tokens à la détecter que si tu avais été transparent.
|
||||
0
.ideai/agents/glm.md
Normal file
0
.ideai/agents/glm.md
Normal file
0
.ideai/agents/qwen3-5-9b.md
Normal file
0
.ideai/agents/qwen3-5-9b.md
Normal file
0
.ideai/agents/qwen3-code-30b.md
Normal file
0
.ideai/agents/qwen3-code-30b.md
Normal file
0
.ideai/agents/testllamacpp.md
Normal file
0
.ideai/agents/testllamacpp.md
Normal file
363
.ideai/mcp-tool-permissions.json
Normal file
363
.ideai/mcp-tool-permissions.json
Normal file
@ -0,0 +1,363 @@
|
||||
{
|
||||
"version": 1,
|
||||
"projectDefault": {
|
||||
"allowedTools": [
|
||||
"idea_list_agents",
|
||||
"idea_context_read",
|
||||
"idea_memory_read",
|
||||
"idea_skill_read",
|
||||
"idea_workstate_read",
|
||||
"idea_ticket_read",
|
||||
"idea_ticket_list",
|
||||
"idea_ticket_read_carnet",
|
||||
"idea_sprint_list",
|
||||
"idea_template_list",
|
||||
"idea_template_read",
|
||||
"idea_ask_agent",
|
||||
"idea_run_in_background",
|
||||
"idea_launch_agent",
|
||||
"idea_stop_agent",
|
||||
"idea_update_context",
|
||||
"idea_context_propose",
|
||||
"idea_memory_write",
|
||||
"idea_workstate_set",
|
||||
"idea_ticket_create",
|
||||
"idea_ticket_update",
|
||||
"idea_ticket_update_status",
|
||||
"idea_ticket_update_priority",
|
||||
"idea_ticket_update_carnet",
|
||||
"idea_ticket_link",
|
||||
"idea_ticket_unlink",
|
||||
"idea_template_create",
|
||||
"idea_template_update",
|
||||
"idea_template_delete",
|
||||
"idea_create_skill"
|
||||
]
|
||||
},
|
||||
"agents": [
|
||||
{
|
||||
"agentId": "a6ced819-b893-4213-b003-9e9dc79b9641",
|
||||
"policy": {
|
||||
"allowedTools": [
|
||||
"idea_list_agents",
|
||||
"idea_context_read",
|
||||
"idea_memory_read",
|
||||
"idea_skill_read",
|
||||
"idea_workstate_read",
|
||||
"idea_ticket_read",
|
||||
"idea_ticket_list",
|
||||
"idea_ticket_read_carnet",
|
||||
"idea_sprint_list",
|
||||
"idea_template_list",
|
||||
"idea_template_read",
|
||||
"idea_ask_agent",
|
||||
"idea_launch_agent",
|
||||
"idea_stop_agent",
|
||||
"idea_update_context",
|
||||
"idea_context_propose",
|
||||
"idea_memory_write",
|
||||
"idea_workstate_set",
|
||||
"idea_create_skill",
|
||||
"idea_ticket_create",
|
||||
"idea_ticket_update",
|
||||
"idea_ticket_update_status",
|
||||
"idea_ticket_update_priority",
|
||||
"idea_ticket_update_carnet",
|
||||
"idea_ticket_link",
|
||||
"idea_ticket_unlink",
|
||||
"idea_template_create",
|
||||
"idea_template_update",
|
||||
"idea_template_delete"
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"agentId": "dce19c75-9669-4e45-b8de-9950025157da",
|
||||
"policy": {
|
||||
"allowedTools": [
|
||||
"idea_list_agents",
|
||||
"idea_context_read",
|
||||
"idea_memory_read",
|
||||
"idea_skill_read",
|
||||
"idea_workstate_read",
|
||||
"idea_ticket_read",
|
||||
"idea_ticket_list",
|
||||
"idea_ticket_read_carnet",
|
||||
"idea_sprint_list",
|
||||
"idea_template_list",
|
||||
"idea_template_read",
|
||||
"idea_ask_agent",
|
||||
"idea_launch_agent",
|
||||
"idea_stop_agent",
|
||||
"idea_update_context",
|
||||
"idea_context_propose",
|
||||
"idea_memory_write",
|
||||
"idea_workstate_set",
|
||||
"idea_create_skill",
|
||||
"idea_ticket_create",
|
||||
"idea_ticket_update",
|
||||
"idea_ticket_update_status",
|
||||
"idea_ticket_update_priority",
|
||||
"idea_ticket_update_carnet",
|
||||
"idea_ticket_link",
|
||||
"idea_ticket_unlink",
|
||||
"idea_template_create",
|
||||
"idea_template_update",
|
||||
"idea_template_delete"
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"agentId": "73c853d1-c0fd-463b-ad17-1d24fefa371f",
|
||||
"policy": {
|
||||
"allowedTools": [
|
||||
"idea_list_agents",
|
||||
"idea_context_read",
|
||||
"idea_memory_read",
|
||||
"idea_skill_read",
|
||||
"idea_workstate_read",
|
||||
"idea_ticket_read",
|
||||
"idea_ticket_list",
|
||||
"idea_ticket_read_carnet",
|
||||
"idea_sprint_list",
|
||||
"idea_template_list",
|
||||
"idea_template_read",
|
||||
"idea_ask_agent",
|
||||
"idea_launch_agent",
|
||||
"idea_stop_agent",
|
||||
"idea_update_context",
|
||||
"idea_context_propose",
|
||||
"idea_memory_write",
|
||||
"idea_workstate_set",
|
||||
"idea_create_skill",
|
||||
"idea_ticket_create",
|
||||
"idea_ticket_update",
|
||||
"idea_ticket_update_status",
|
||||
"idea_ticket_update_priority",
|
||||
"idea_ticket_update_carnet",
|
||||
"idea_ticket_link",
|
||||
"idea_ticket_unlink",
|
||||
"idea_template_create",
|
||||
"idea_template_update",
|
||||
"idea_template_delete"
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"agentId": "af7f86da-76bc-48e1-9900-71f45a624800",
|
||||
"policy": {
|
||||
"allowedTools": [
|
||||
"idea_list_agents",
|
||||
"idea_context_read",
|
||||
"idea_memory_read",
|
||||
"idea_skill_read",
|
||||
"idea_workstate_read",
|
||||
"idea_ticket_read",
|
||||
"idea_ticket_list",
|
||||
"idea_ticket_read_carnet",
|
||||
"idea_sprint_list",
|
||||
"idea_template_list",
|
||||
"idea_template_read",
|
||||
"idea_ask_agent",
|
||||
"idea_launch_agent",
|
||||
"idea_stop_agent",
|
||||
"idea_update_context",
|
||||
"idea_context_propose",
|
||||
"idea_memory_write",
|
||||
"idea_workstate_set",
|
||||
"idea_create_skill",
|
||||
"idea_ticket_create",
|
||||
"idea_ticket_update",
|
||||
"idea_ticket_update_status",
|
||||
"idea_ticket_update_priority",
|
||||
"idea_ticket_update_carnet",
|
||||
"idea_ticket_link",
|
||||
"idea_ticket_unlink",
|
||||
"idea_template_create",
|
||||
"idea_template_update",
|
||||
"idea_template_delete"
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"agentId": "aefdbd61-e3d4-4bc1-9f42-c259446a97b5",
|
||||
"policy": {
|
||||
"allowedTools": [
|
||||
"idea_list_agents",
|
||||
"idea_context_read",
|
||||
"idea_memory_read",
|
||||
"idea_skill_read",
|
||||
"idea_workstate_read",
|
||||
"idea_ticket_read",
|
||||
"idea_ticket_list",
|
||||
"idea_ticket_read_carnet",
|
||||
"idea_sprint_list",
|
||||
"idea_template_list",
|
||||
"idea_template_read",
|
||||
"idea_ask_agent",
|
||||
"idea_launch_agent",
|
||||
"idea_stop_agent",
|
||||
"idea_update_context",
|
||||
"idea_context_propose",
|
||||
"idea_memory_write",
|
||||
"idea_workstate_set",
|
||||
"idea_create_skill",
|
||||
"idea_ticket_create",
|
||||
"idea_ticket_update",
|
||||
"idea_ticket_update_status",
|
||||
"idea_ticket_update_priority",
|
||||
"idea_ticket_update_carnet",
|
||||
"idea_ticket_link",
|
||||
"idea_ticket_unlink",
|
||||
"idea_template_create",
|
||||
"idea_template_update",
|
||||
"idea_template_delete"
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"agentId": "cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5",
|
||||
"policy": {
|
||||
"allowedTools": [
|
||||
"idea_list_agents",
|
||||
"idea_context_read",
|
||||
"idea_memory_read",
|
||||
"idea_skill_read",
|
||||
"idea_workstate_read",
|
||||
"idea_ticket_read",
|
||||
"idea_ticket_list",
|
||||
"idea_ticket_read_carnet",
|
||||
"idea_sprint_list",
|
||||
"idea_template_list",
|
||||
"idea_template_read",
|
||||
"idea_ask_agent",
|
||||
"idea_launch_agent",
|
||||
"idea_stop_agent",
|
||||
"idea_update_context",
|
||||
"idea_context_propose",
|
||||
"idea_memory_write",
|
||||
"idea_workstate_set",
|
||||
"idea_create_skill",
|
||||
"idea_ticket_create",
|
||||
"idea_ticket_update",
|
||||
"idea_ticket_update_status",
|
||||
"idea_ticket_update_priority",
|
||||
"idea_ticket_update_carnet",
|
||||
"idea_ticket_link",
|
||||
"idea_ticket_unlink",
|
||||
"idea_template_create",
|
||||
"idea_template_update",
|
||||
"idea_template_delete"
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"agentId": "c3e0d9d8-df36-4b00-b271-62d8aa78892c",
|
||||
"policy": {
|
||||
"allowedTools": [
|
||||
"idea_list_agents",
|
||||
"idea_context_read",
|
||||
"idea_memory_read",
|
||||
"idea_skill_read",
|
||||
"idea_workstate_read",
|
||||
"idea_ticket_read",
|
||||
"idea_ticket_list",
|
||||
"idea_ticket_read_carnet",
|
||||
"idea_sprint_list",
|
||||
"idea_template_list",
|
||||
"idea_template_read",
|
||||
"idea_ask_agent",
|
||||
"idea_launch_agent",
|
||||
"idea_stop_agent",
|
||||
"idea_update_context",
|
||||
"idea_context_propose",
|
||||
"idea_memory_write",
|
||||
"idea_workstate_set",
|
||||
"idea_create_skill",
|
||||
"idea_ticket_create",
|
||||
"idea_ticket_update",
|
||||
"idea_ticket_update_status",
|
||||
"idea_ticket_update_priority",
|
||||
"idea_ticket_update_carnet",
|
||||
"idea_ticket_link",
|
||||
"idea_ticket_unlink",
|
||||
"idea_template_create",
|
||||
"idea_template_update",
|
||||
"idea_template_delete"
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"agentId": "5d07e4a7-8676-4a71-aea1-5b64caefa944",
|
||||
"policy": {
|
||||
"allowedTools": [
|
||||
"idea_list_agents",
|
||||
"idea_context_read",
|
||||
"idea_memory_read",
|
||||
"idea_skill_read",
|
||||
"idea_workstate_read",
|
||||
"idea_ticket_read",
|
||||
"idea_ticket_list",
|
||||
"idea_ticket_read_carnet",
|
||||
"idea_sprint_list",
|
||||
"idea_template_list",
|
||||
"idea_template_read",
|
||||
"idea_ask_agent",
|
||||
"idea_launch_agent",
|
||||
"idea_stop_agent",
|
||||
"idea_update_context",
|
||||
"idea_context_propose",
|
||||
"idea_memory_write",
|
||||
"idea_workstate_set",
|
||||
"idea_create_skill",
|
||||
"idea_ticket_create",
|
||||
"idea_ticket_update",
|
||||
"idea_ticket_update_status",
|
||||
"idea_ticket_update_priority",
|
||||
"idea_ticket_update_carnet",
|
||||
"idea_ticket_link",
|
||||
"idea_ticket_unlink",
|
||||
"idea_template_create",
|
||||
"idea_template_update",
|
||||
"idea_template_delete"
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"agentId": "30bf7e5f-5681-478d-813c-ac4c3957897f",
|
||||
"policy": {
|
||||
"allowedTools": [
|
||||
"idea_list_agents",
|
||||
"idea_context_read",
|
||||
"idea_memory_read",
|
||||
"idea_skill_read",
|
||||
"idea_workstate_read",
|
||||
"idea_ticket_read",
|
||||
"idea_ticket_list",
|
||||
"idea_ticket_read_carnet",
|
||||
"idea_sprint_list",
|
||||
"idea_template_list",
|
||||
"idea_template_read",
|
||||
"idea_ask_agent",
|
||||
"idea_launch_agent",
|
||||
"idea_stop_agent",
|
||||
"idea_update_context",
|
||||
"idea_context_propose",
|
||||
"idea_memory_write",
|
||||
"idea_workstate_set",
|
||||
"idea_create_skill",
|
||||
"idea_ticket_create",
|
||||
"idea_ticket_update",
|
||||
"idea_ticket_update_status",
|
||||
"idea_ticket_update_priority",
|
||||
"idea_ticket_update_carnet",
|
||||
"idea_ticket_link",
|
||||
"idea_ticket_unlink",
|
||||
"idea_template_create",
|
||||
"idea_template_update",
|
||||
"idea_template_delete"
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
@ -8,55 +8,26 @@
|
||||
- [session-limit-handling-design](session-limit-handling-design.md) — Design valide (detecteur hierarchique + reprise auto annulable) pour les limites de session des agents.
|
||||
- [git-owns-commit-merge-decisions](git-owns-commit-merge-decisions.md) — Ne jamais demander a l'utilisateur s'il faut committer/merger/brancher : l'agent Git tranche toute la topologie du depot.
|
||||
- [conversation-rotation-safety-design](conversation-rotation-safety-design.md) — memory note conversation-rotation-safety-design
|
||||
- [checkpoint-orchestrator-designation-restart](checkpoint-orchestrator-designation-restart.md) — memory note checkpoint-orchestrator-designation-restart
|
||||
- [checkpoint-orchestrator-designation-backend-compile-fix](checkpoint-orchestrator-designation-backend-compile-fix.md) — memory note checkpoint-orchestrator-designation-backend-compile-fix
|
||||
- [checkpoint-orchestrator-designation-qa-verdict](checkpoint-orchestrator-designation-qa-verdict.md) — memory note checkpoint-orchestrator-designation-qa-verdict
|
||||
- [checkpoint-orchestrator-designation-appimage-build](checkpoint-orchestrator-designation-appimage-build.md) — memory note checkpoint-orchestrator-designation-appimage-build
|
||||
- [checkpoint-blocked-until-appimage-030-restart](checkpoint-blocked-until-appimage-030-restart.md) — memory note checkpoint-blocked-until-appimage-030-restart
|
||||
- [checkpoint-delivery-submit-logging-fix](checkpoint-delivery-submit-logging-fix.md) — memory note checkpoint-delivery-submit-logging-fix
|
||||
- [checkpoint-workstate-delegation-queue-lot-b](checkpoint-workstate-delegation-queue-lot-b.md) — memory note checkpoint-workstate-delegation-queue-lot-b
|
||||
- [checkpoint-workstate-conversation-summaries-lot-c](checkpoint-workstate-conversation-summaries-lot-c.md) — memory note checkpoint-workstate-conversation-summaries-lot-c
|
||||
- [checkpoint-workstate-controlled-actions-lot-d](checkpoint-workstate-controlled-actions-lot-d.md) — memory note checkpoint-workstate-controlled-actions-lot-d
|
||||
- [checkpoint-work-tab-blank-fix](checkpoint-work-tab-blank-fix.md) — memory note checkpoint-work-tab-blank-fix
|
||||
- [skills-integration-canonical-foundation](skills-integration-canonical-foundation.md) — Topologie d'intégration du chantier skills agent et décision d'abandon de feature/agent-skills.
|
||||
- [idea-program-surface-separation-and-livestate](idea-program-surface-separation-and-livestate.md) — Cadrage du programme post-skills : ce qui existe vs reste, et la règle de frontière surface-agent/humaine.
|
||||
- [handoff-ls5-summary-bound-and-llm-seam](handoff-ls5-summary-bound-and-llm-seam.md) — Contrat figé de la borne de handoff (perf) et du seam résumeur LLM non activé.
|
||||
- [conversation-log-ls6-rotation-and-paginated-read](conversation-log-ls6-rotation-and-paginated-read.md) — Contrat figé de la rétention/rotation du transcript et de la lecture paginée riche (surface humaine).
|
||||
- [conversation-viewer-ls7-frontend](conversation-viewer-ls7-frontend.md) — Contrat figé du viewer de transcript paginé (frontend pur, lecture seule, surface humaine).
|
||||
- [live-state-persistence-program-closed-ls8](live-state-persistence-program-closed-ls8.md) — Le programme live-state + persistance conversationnelle est livré et documenté ; pointe la doc de clôture et les points restés ouverts.
|
||||
- [resume-after-appimage-rebuild-mcp-e2e](resume-after-appimage-rebuild-mcp-e2e.md) — memory note resume-after-appimage-rebuild-mcp-e2e
|
||||
- [mcp-e2e-findings-reply-wedge-phantom-busy](mcp-e2e-findings-reply-wedge-phantom-busy.md) — memory note mcp-e2e-findings-reply-wedge-phantom-busy
|
||||
- [checkpoint-finding-a-fix-built-live-validation-pending](checkpoint-finding-a-fix-built-live-validation-pending.md) — memory note checkpoint-finding-a-fix-built-live-validation-pending
|
||||
- [git-agent-push-access-gitea-ssh](git-agent-push-access-gitea-ssh.md) — memory note git-agent-push-access-gitea-ssh
|
||||
- [rendezvous-no-reply-backstop-design](rendezvous-no-reply-backstop-design.md) — Décision d'architecture sur la fin-de-tour et le backstop no-reply du rendez-vous idea_ask_agent ⇄ idea_reply, après échec live du fix Finding A (77e62e5).
|
||||
- [checkpoint-rendezvous-redesign-devbackend-todo](checkpoint-rendezvous-redesign-devbackend-todo.md) — memory note checkpoint-rendezvous-redesign-devbackend-todo
|
||||
- [backstop-no-reply-live-test-failed-2026-06-23](backstop-no-reply-live-test-failed-2026-06-23.md) — memory note backstop-no-reply-live-test-failed-2026-06-23
|
||||
- [live-state-reboot-reconciliation-design](live-state-reboot-reconciliation-design.md) — memory note live-state-reboot-reconciliation-design
|
||||
- [reconcile-live-state-implemented-feature-branch](reconcile-live-state-implemented-feature-branch.md) — memory note reconcile-live-state-implemented-feature-branch
|
||||
- [rendezvous-600s-cap-too-short-heavy-tasks](rendezvous-600s-cap-too-short-heavy-tasks.md) — memory note rendezvous-600s-cap-too-short-heavy-tasks
|
||||
- [backstop-fires-on-intra-task-turn-rootcause](backstop-fires-on-intra-task-turn-rootcause.md) — memory note backstop-fires-on-intra-task-turn-rootcause
|
||||
- [mcp-functional-test-plan-2026-06-24](mcp-functional-test-plan-2026-06-24.md) — memory note mcp-functional-test-plan-2026-06-24
|
||||
- [checkpoint-mcp-tests-t1-t5-and-t5-livestate-defect](checkpoint-mcp-tests-t1-t5-and-t5-livestate-defect.md) — memory note checkpoint-mcp-tests-t1-t5-and-t5-livestate-defect
|
||||
- [checkpoint-mcp-t1-t6-green-t7-fix-wrong-layer](checkpoint-mcp-t1-t6-green-t7-fix-wrong-layer.md) — memory note checkpoint-mcp-t1-t6-green-t7-fix-wrong-layer
|
||||
- [mcp-t7-backstop-600s-reply-rejected-livestate-stale](mcp-t7-backstop-600s-reply-rejected-livestate-stale.md) — memory note mcp-t7-backstop-600s-reply-rejected-livestate-stale
|
||||
- [mcp-functional-tests-t1-t9-green-live-2026-06-24](mcp-functional-tests-t1-t9-green-live-2026-06-24.md) — memory note mcp-functional-tests-t1-t9-green-live-2026-06-24
|
||||
- [mcp-t10a-harness-interrupt-does-not-cancel-rendezvous](mcp-t10a-harness-interrupt-does-not-cancel-rendezvous.md) — memory note mcp-t10a-harness-interrupt-does-not-cancel-rendezvous
|
||||
- [mcp-t10b-pending-reboot-verification](mcp-t10b-pending-reboot-verification.md) — memory note mcp-t10b-pending-reboot-verification
|
||||
- [headless-interagent-conversation-objective](headless-interagent-conversation-objective.md) — memory note headless-interagent-conversation-objective
|
||||
- [checkpoint-b2-bootstrap-applied-await-codex-reset-1430](checkpoint-b2-bootstrap-applied-await-codex-reset-1430.md) — memory note checkpoint-b2-bootstrap-applied-await-codex-reset-1430
|
||||
- [background-tasks-first-class-design](background-tasks-first-class-design.md) — memory note background-tasks-first-class-design
|
||||
- [b7-wiring-anchor-state-rs](b7-wiring-anchor-state-rs.md) — memory note b7-wiring-anchor-state-rs
|
||||
- [appimage-build-no-strip-relr-dyn-fix](appimage-build-no-strip-relr-dyn-fix.md) — memory note appimage-build-no-strip-relr-dyn-fix
|
||||
- [checkpoint-b7-blocked-codex-session-limit](checkpoint-b7-blocked-codex-session-limit.md) — memory note checkpoint-b7-blocked-codex-session-limit
|
||||
- [issue-ticket-system-design](issue-ticket-system-design.md) — memory note issue-ticket-system-design
|
||||
- [checkpoint-issue-ticket-backend-v1-done](checkpoint-issue-ticket-backend-v1-done.md) — memory note checkpoint-issue-ticket-backend-v1-done
|
||||
- [tickets-frontend-v1-done](tickets-frontend-v1-done.md) — État du frontend du système de tickets — livré, vert, décisions de contrat clés.
|
||||
- [tickets-v1-e2e-validated-qa](tickets-v1-e2e-validated-qa.md) — Verdict QA du système de tickets V1 sans attachments sur feature/issue-ticket-system — vert de bout en bout, avec la seule réserve du typage de conflit côté UI.
|
||||
- [b8-command-runner-pty-framing](b8-command-runner-pty-framing.md) — Cadrage hexagonal figé du lot B8 : runner concret sur le port BackgroundTaskRunner, fermeture de la boucle sink en composition root, contrat de complétion, commandes cancel/retry.
|
||||
- [checkpoint-b8-command-runner-loop-closed](checkpoint-b8-command-runner-loop-closed.md) — memory note checkpoint-b8-command-runner-loop-closed
|
||||
- [b8-arbitration-outcomes](b8-arbitration-outcomes.md) — Décisions d'arbitrage Architecture sur les 5 écarts B8 remontés par DevBackend : ce qui reste dans B8 vs part en dette/ticket.
|
||||
- [b8-in-app-trigger-run-in-background](b8-in-app-trigger-run-in-background.md) — Arbitrage de l'écart de périmètre #1 — la surface agent MCP idea_run_in_background ferme la boucle B8, contrat et lots figés.
|
||||
- [checkpoint-t1-wake-delivery-bug-fixed-rebuild-pending](checkpoint-t1-wake-delivery-bug-fixed-rebuild-pending.md) — memory note checkpoint-t1-wake-delivery-bug-fixed-rebuild-pending
|
||||
- [workstate-background-tasks-projection-fix](workstate-background-tasks-projection-fix.md) — Décision d'archi pour rendre visibles Cancel/Retry dans le panneau Work — extension du read-model GetProjectWorkState, contrat DTO et borne de livraison.
|
||||
- [tickets-t3-frontend-validation-verdict](tickets-t3-frontend-validation-verdict.md) — Verdict de validation frontend du fix T3 (projection backgroundTasks par agent) sur feature/background-tasks-first-class — vert, avec 3 désalignements de contrat mineurs.
|
||||
- [ticket4-restart-on-develop-ebd992e](ticket4-restart-on-develop-ebd992e.md) — Cadrage du redémarrage des annonces inter-agent sur la base pré-canonique develop ebd992e — ce qui existe, l'écart live, la réutilisabilité du backup et le découpage B/F.
|
||||
@ -75,5 +46,31 @@
|
||||
- [ticket28-f1-frontend-delivered](ticket28-f1-frontend-delivered.md) — Lot F1 du ticket #28 livré sur feature/ticket28-firstrun-detect-hang — invariant busy/detectProfiles, flag detecting, timeout UI, test de non-régression.
|
||||
- [opencode-llamacpp-replaces-ollama](opencode-llamacpp-replaces-ollama.md) — memory note opencode-llamacpp-replaces-ollama
|
||||
- [f36-multi-opencode-profiles-frontend](f36-multi-opencode-profiles-frontend.md) — Multiplicité des profils OpenCode locaux côté UI first-run wizard — livrée, verte, sans gap backend.
|
||||
- [f35-launch-status-done-config-crud-blocked](f35-launch-status-done-config-crud-blocked.md) — F35.1 UI statut de lancement du serveur local livrée+verte ; F35.2 config CRUD bloquée sur un DTO figé qui ne matche pas le wire réel + delete manquant.
|
||||
- [f35-config-crud-delivered](f35-config-crud-delivered.md) — F35.2 (config serveur local + sélection dans les profils OpenCode) livrée et verte sur feature/modeles-locaux ; clôt le sprint modèles locaux F34-F36.
|
||||
- [develop-realigned-to-cli-ui-baseline-2026-07-02](develop-realigned-to-cli-ui-baseline-2026-07-02.md) — Décision de topologie (validée utilisateur) : develop réaligné sur la ligne UI CLI (pre-chat-ui-baseline).
|
||||
- [feature-agent-skill-awareness-design](feature-agent-skill-awareness-design.md) — Design validé + découpage de la feature « surfacer les skills assignés à un agent à la manière MCP » (manifeste + idea_skill_read).
|
||||
- [inter-agent-announcements-feature-and-codex-final-bug](inter-agent-announcements-feature-and-codex-final-bug.md) — Design figé des annonces inter-agent (UI live) + cause racine du bug Final Codex, validé utilisateur le 2026-07-02.
|
||||
- [inter-agent-live-context-shared-per-agent](inter-agent-live-context-shared-per-agent.md) — Décision d'architecture figée : le contexte live inter-agent est PAR AGENT (partagé), pas par paire (validée utilisateur 2026-07-02).
|
||||
- [ticket4-announcements-frontend-f1f2f3](ticket4-announcements-frontend-f1f2f3.md) — Topologie du frontend des annonces inter-agent (store borné, preview requester filtré, overlay cible piloté par le busy/idle par agent) — réintégré sur base develop.
|
||||
- [ticket54-f1-model-download-overlay-frontend](ticket54-f1-model-download-overlay-frontend.md) — Overlay plein-cellule de préparation du serveur modèle local + progression (barre/%/bytes/source), corrélation factorisée, priorité de voile.
|
||||
- [ticket56-visibleelsewhere-derives-from-layout](ticket56-visibleelsewhere-derives-from-layout.md) — Fix frontend du sélecteur d'agent : la désactivation « visible ailleurs » doit venir du layout courant, pas du dernier nodeId du live registry.
|
||||
- [ticket13-f0-frontend-transport-inventory](ticket13-f0-frontend-transport-inventory.md) — Résultat de l'inventaire B0/F0 frontend du chantier client/serveur #13 — la frontière gateways transport-neutres existe déjà, F1 = ajout d'adapters HTTP+WS.
|
||||
- [ticket13-f1-http-ws-adapter-delivered](ticket13-f1-http-ws-adapter-delivered.md) — Le 3e jeu d'adapters frontend (HTTP request/response + squelette WebSocket) du chantier client/serveur #13 est livré et vert, derrière les ports inchangés.
|
||||
- [ticket13-f2-web-readonly-client-delivered](ticket13-f2-web-readonly-client-delivered.md) — Le client web read-only (pairing cookie, liste projets, ouverture read-only + snapshot work-state) du chantier client/serveur #13 est livré et vert.
|
||||
- [ticket13-f3-xterm-websocket-delivered](ticket13-f3-xterm-websocket-delivered.md) — L'adapter WS terminal (round-trip xterm, reconnexion+replay, états connexion) du chantier client/serveur #13 est finalisé et vert côté frontend.
|
||||
- [ticket13-f4-web-agent-surface-delivered](ticket13-f4-web-agent-surface-delivered.md) — L'agent CLI web (agent.launch → terminal.attached, réattache sans relance, cellule agent réutilisant TerminalView) du chantier client/serveur #13 est livré et vert côté frontend.
|
||||
- [ticket13-f5-web-live-surfaces-delivered](ticket13-f5-web-live-surfaces-delivered.md) — Les surfaces live web (workstate live via event.domain, background tasks cancel/retry, inbox, re-synchro au reconnect) du chantier client/serveur #13 sont livrées et vertes.
|
||||
- [frontend-uses-npm-not-pnpm](frontend-uses-npm-not-pnpm.md) — memory note frontend-uses-npm-not-pnpm
|
||||
- [idea-distribution-strategy-desktop-vs-docker](idea-distribution-strategy-desktop-vs-docker.md) — memory note idea-distribution-strategy-desktop-vs-docker
|
||||
- [web-client-is-single-column-no-desktop-shell](web-client-is-single-column-no-desktop-shell.md) — memory note web-client-is-single-column-no-desktop-shell
|
||||
- [sandbox-eperm-bind-false-green-web-server](sandbox-eperm-bind-false-green-web-server.md) — memory note sandbox-eperm-bind-false-green-web-server
|
||||
- [ticket74-f1-web-bundle-transport-seam](ticket74-f1-web-bundle-transport-seam.md) — Deux artefacts Vite (dist/dist-web), mode `web` portable Windows, et le câblage anti-divergence de la constante de transport.
|
||||
- [ticket43-backend-b1-b4-qa-validation](ticket43-backend-b1-b4-qa-validation.md) — memory note ticket43-backend-b1-b4-qa-validation
|
||||
- [ticket43-plugin-system-final-qa-verdict](ticket43-plugin-system-final-qa-verdict.md) — memory note ticket43-plugin-system-final-qa-verdict
|
||||
- [ticket101-cross-talk-multi-project-rootcause](ticket101-cross-talk-multi-project-rootcause.md) — memory note ticket101-cross-talk-multi-project-rootcause
|
||||
- [ticket103-network-permission-ux-surface](ticket103-network-permission-ux-surface.md) — Stable UX convention for agent network permissions in IdeA.
|
||||
- [codex-network-access-config-fix](codex-network-access-config-fix.md) — memory note codex-network-access-config-fix
|
||||
- [multi-profile-codex-claude-model-catalogue-scoping](multi-profile-codex-claude-model-catalogue-scoping.md) — memory note multi-profile-codex-claude-model-catalogue-scoping
|
||||
- [model-catalogue-compat-cadrage](model-catalogue-compat-cadrage.md) — Frontières hexagonales, ports, DTO, fallback et matrice de compatibilité versionnée pour l'évolution du catalogue de modèles des profils structurés Codex/Claude.
|
||||
- [tickets-70-100-102-ux-surface-scoping](tickets-70-100-102-ux-surface-scoping.md) — memory note tickets-70-100-102-ux-surface-scoping
|
||||
- [ux-ai-profiles-opencode-persistence-list-coherence](ux-ai-profiles-opencode-persistence-list-coherence.md) — memory note ux-ai-profiles-opencode-persistence-list-coherence
|
||||
|
||||
@ -6,7 +6,7 @@ metadata:
|
||||
---
|
||||
---
|
||||
name: appimage-build-no-strip-relr-dyn-fix
|
||||
description: Le build AppImage échoue sur cette machine (CachyOS/Arch) à l'étape linuxdeploy/strip (.relr.dyn) ; correctif = NO_STRIP=true. Explique probablement les "builds qui ne produisent rien".
|
||||
description: Le build AppImage échoue sur cette machine (CachyOS/Arch) à l'étape linuxdeploy/strip (.relr.dyn) ; correctif = NO_STRIP=true. Séquence de build mise à jour après #74 (beforeBuildCommand = build:bundle).
|
||||
metadata:
|
||||
type: reference
|
||||
---
|
||||
@ -30,7 +30,7 @@ section ELF moderne `.relr.dyn` (relocations `DT_RELR`, `unknown type [0x13]`) p
|
||||
libs système GTK/glibc de CachyOS/Arch (rolling). Le plugin `gtk` de linuxdeploy strip ces libs
|
||||
→ échec → tout le bundling casse.
|
||||
|
||||
## Correctif VALIDÉ (2026-07-02)
|
||||
## Correctif VALIDÉ (2026-07-02, toujours valable 2026-07-17)
|
||||
Lancer le build avec `NO_STRIP=true` (le binaire release est déjà strippé par cargo) :
|
||||
```
|
||||
cd crates/app-tauri
|
||||
@ -38,15 +38,40 @@ NO_STRIP=true ../../frontend/node_modules/.bin/tauri build --bundles appimage
|
||||
```
|
||||
Résultat : `Finished 1 bundle at target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`.
|
||||
|
||||
## Séquence de build complète (rappel, pas de beforeBuildCommand dans tauri.conf.json)
|
||||
1. `npm --prefix frontend run build` (produit `frontend/dist`).
|
||||
2. depuis `crates/app-tauri` : `NO_STRIP=true <cli tauri> build --bundles appimage`.
|
||||
CLI tauri = `frontend/node_modules/.bin/tauri` (@tauri-apps/cli). Config = crates/app-tauri/tauri.conf.json.
|
||||
## Séquence de build — MISE À JOUR après #74 (2026-07-17)
|
||||
**Attention : l'ancienne version de cette note disait « pas de beforeBuildCommand dans
|
||||
tauri.conf.json » et imposait un `npm run build` manuel préalable. C'est FAUX depuis #74.**
|
||||
|
||||
`crates/app-tauri/tauri.conf.json` a maintenant :
|
||||
- `build.beforeBuildCommand: "npm --prefix ../frontend run build:bundle"`
|
||||
- `bundle.resources: { "../../frontend/dist-web": "web" }`
|
||||
|
||||
et `frontend/package.json` définit :
|
||||
```
|
||||
"build:bundle": "npm run typecheck && vite build --outDir dist --emptyOutDir && vite build --mode web --outDir dist-web --emptyOutDir"
|
||||
```
|
||||
|
||||
Donc **une seule commande suffit**, le frontend est construit automatiquement (les DEUX bundles) :
|
||||
```
|
||||
cd crates/app-tauri
|
||||
NO_STRIP=true ../../frontend/node_modules/.bin/tauri build --bundles appimage
|
||||
```
|
||||
|
||||
`build:bundle` produit **deux** bundles distincts, et c'est le cœur du fix #74 :
|
||||
- `frontend/dist` → bundle **desktop**, transport `tauri` (= `build.frontendDist`).
|
||||
- `frontend/dist-web` → bundle **web**, transport `http` (= packagé en ressource `web/`).
|
||||
|
||||
Un seul `dist` ne peut pas servir les deux : le transport est figé **au build** par Vite
|
||||
(`resolveTransport()` lit `import.meta.env.VITE_TRANSPORT`, constant-folded). C'est ce qui
|
||||
causait `__TAURI_INTERNALS__ is undefined` dans le navigateur (#74).
|
||||
|
||||
Garde-fou : `npm run test:bundle-transport` vérifie que `dist` = tauri et `dist-web` = http.
|
||||
Le lancer après un build si un doute subsiste sur ce qui est servi au navigateur.
|
||||
|
||||
## Implication produit
|
||||
C'est très probablement la vraie cause des « builds AppImage qui ne produisent rien / attente
|
||||
sans résultat » signalés par l'utilisateur. À intégrer idéalement dans le flux de build d'IdeA
|
||||
(passer NO_STRIP quand on cible AppImage sur Arch, ou vendoriser un linuxdeploy récent).
|
||||
|
||||
Lien : [[mcp-bridge-and-delegation-runtime-notes]],
|
||||
[[checkpoint-b2-bootstrap-applied-await-codex-reset-1430]].
|
||||
Lien : [[mcp-bridge-and-delegation-runtime-notes]] (le binaire qui tourne = AppImage, pas les
|
||||
sources — rebuild obligatoire pour tester un changement backend live).
|
||||
@ -1,34 +0,0 @@
|
||||
---
|
||||
name: backstop-fires-on-intra-task-turn-rootcause
|
||||
description: memory note backstop-fires-on-intra-task-turn-rootcause
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
title: CAUSE RACINE — le backstop tire sur chaque tour interne (turn_duration ≠ retour-au-prompt)
|
||||
type: project
|
||||
description: Le turn-watcher fait tirer le backstop no-reply au PREMIER turn_duration, soit le 1er pas d'agent interne — il casse toute délégation multi-étapes (libération prématurée + rapport perdu). Le test QA pong passait par chance (tâche mono-tour).
|
||||
---
|
||||
# CAUSE RACINE (2026-06-23, prouvée live) — backstop tire sur les tours INTERNES
|
||||
|
||||
## Preuve
|
||||
Cadrage délégué à Architect (tâche multi-étapes, lecture de code) :
|
||||
```
|
||||
562100 [rendezvous] ask started -> Architect turn_timeout_ms=600000
|
||||
564943 [rendezvous] ask returned-to-prompt-no-reply: Architect after_ms=2843
|
||||
564943 [mailbox] complete_without_reply agent=dce19c75 ticket=cc4067fa outcome=sent
|
||||
```
|
||||
- Tiré à **2843 ms** : impossible qu'Architect ait fini un cadrage en 2,8 s.
|
||||
- Au même instant, transcript Architect **toujours en écriture** (Bash/Read en boucle), `idea_reply` count = **0** → Architect **continuait à travailler**.
|
||||
- Transcript = **61 `turn_duration`** : Claude écrit un `turn_duration` **par tour d'agent interne** (chaque appel LLM de la boucle agentique), PAS seulement au retour-au-prompt final.
|
||||
|
||||
## Diagnostic
|
||||
`claude_turn_watcher.rs` fait tirer `turn_ended` au **premier incrément** de `turn_duration` au-dessus de la baseline. Or cet incrément survient dès le **1er pas interne** de l'agent (~secondes). Donc le backstop confond « l'agent a fait un pas de raisonnement » avec « l'agent est retourné au prompt sans répondre ». Pour **toute tâche multi-étapes** : libération prématurée du demandeur « sans réponse » pendant que la cible bosse encore → `idea_reply` final → « no pending request » → **rapport perdu** (travail survit sur disque/branche).
|
||||
|
||||
Le test QA « pong » (backstop-no-reply-live-test-failed-2026-06-23, devenu vert) passait **par chance** : tâche à **un seul tour** ⇒ premier tour = dernier tour. Le fix `encode_cwd` a fait tirer le watcher correctement, mais a **révélé que la CONDITION de tir est fausse**.
|
||||
|
||||
## Conséquence opérationnelle
|
||||
Avec le binaire courant, **aucune délégation substantielle (multi-tours) ne remonte son rapport** : elle est coupée à ~3 s. Workaround Main en attendant le fix : déléguer → surveiller le transcript de la cible jusqu'à inactivité (mtime stable) → récupérer le résultat sur disque/branche ou re-solliciter en léger.
|
||||
|
||||
## Implication pour la refonte (seam liveness/fin-de-tour, validée utilisateur)
|
||||
« Retourné au prompt idle » NE peut PAS être « un turn_duration est apparu ». Le bon signal = **process vivant (`is_agent_live`) + transcript NE grossit PLUS depuis stall_after_ms** (battement de cœur). Tant que le transcript grossit ⇒ l'agent travaille ⇒ ne pas libérer. Le 1er lot du fix devrait **neutraliser ce tir prématuré**. Lié à [[rendezvous-600s-cap-too-short-heavy-tasks]], [[rendezvous-no-reply-backstop-design]], [[backstop-no-reply-live-test-failed-2026-06-23]].
|
||||
@ -1,34 +0,0 @@
|
||||
---
|
||||
name: backstop-no-reply-live-test-failed-2026-06-23
|
||||
description: memory note backstop-no-reply-live-test-failed-2026-06-23
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
title: Backstop no-reply — RE-VALIDATION LIVE VERTE (wedge levé) après fix encode_cwd
|
||||
type: project
|
||||
description: Le backstop no-reply du rendez-vous est validé en live le 2026-06-23 (session post-rebuild) : demandeur libéré ~grâce 2s au lieu de 600s. Reste un point de finition (résultat véhiculé via canal d'erreur).
|
||||
---
|
||||
|
||||
# Backstop no-reply — RE-VALIDATION LIVE : VERTE (2026-06-23, session post-rebuild)
|
||||
|
||||
Remplace le 1er test (ÉCHEC) du même jour. La cause racine était l'encodage du slug projet Claude (`.` non encodé) corrigé dans `crates/infrastructure/src/inspector/claude_paths.rs` (`encode_cwd` → `replace(/[^a-zA-Z0-9]/g,'-')`, double-tiret sur `/.ideai/`). Voir [[checkpoint-rendezvous-redesign-devbackend-todo]] pour la cause racine.
|
||||
|
||||
## Preuves live (idea.log, session a6ced819)
|
||||
Scénario : DevBackend → idea_ask_agent vers QA « pong en prose, SANS idea_reply (volontaire) ».
|
||||
|
||||
```
|
||||
912948 [mcp] ask armed requester=DevBackend(73c853d1) target=QA timeout_ms=600000
|
||||
917707 [turn-watcher] turn_duration detected agent=QA(aefdbd61) count 47->48 -> turn_ended
|
||||
917707 [input-mediator] turn_ended agent=QA no_reply_payload -> mark_idle + grace
|
||||
917707 [input-mediator] turn_ended arming grace agent=QA ticket=0257c630 grace_ms=2000
|
||||
919707 [mailbox] complete_without_reply agent=QA ticket=0257c630 queue_depth_before=1 after=0 outcome=sent
|
||||
```
|
||||
|
||||
Contraste avec l'échec précédent : `turn_ended` = 0 avant le fix, ici il FIRE ; `arm … dir=…IdeA--ideai-run-…` sur dossier EXISTANT ; grâce 2s exacte (917707→919707) ; libération du demandeur via `complete_without_reply outcome=sent`. DevBackend a repris la main en ~13 s mesuré (pas 600 s). Aucun wedge, aucun cascade-timeout.
|
||||
|
||||
## Point de finition résiduel (NON bloquant, follow-up)
|
||||
Le résultat rendu au demandeur passe par le **canal d'erreur** MCP : « agent QA returned to its prompt without calling idea_reply (no answer was rendered); retry the request and ensure the agent replies via idea_reply ». Ce n'est pas un résultat no-reply synthétique structuré (design item c de [[rendezvous-no-reply-backstop-design]]) ; pour un orchestrateur c'est mal distinguable d'un échec transitoire « retry ». À transformer en verdict consommable (follow-up, hors blocage merge).
|
||||
|
||||
## Suite
|
||||
Wedge prouvé levé en live ⇒ garde-fou Git satisfait. Délégué à Git : commit du fix `encode_cwd` (+ test de non-régression `encode_cwd_encodes_dot_in_run_dir_to_double_dash`) sur la branche du backstop, puis décision de merge develop.
|
||||
@ -1,62 +0,0 @@
|
||||
---
|
||||
name: checkpoint-auto-memory-harvest-lot-e1
|
||||
description: memory note checkpoint-auto-memory-harvest-lot-e1
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Checkpoint — Auto-memory harvest Lot E1
|
||||
|
||||
Date: 2026-06-21
|
||||
|
||||
## État final
|
||||
|
||||
Lot E1 `auto-memory harvest contrôlé` terminé, validé QA et mergé localement dans `develop`.
|
||||
|
||||
Branche finale:
|
||||
- `develop` @ `61c330a` — merge local `feature/controlled-auto-memory-harvest`.
|
||||
- Branche `feature/controlled-auto-memory-harvest` supprimée après merge.
|
||||
- Aucun push, aucun merge vers `main`.
|
||||
- Working tree applicatif propre; seuls résidus non committés: bruit runtime `.ideai/*` volontairement exclu.
|
||||
|
||||
## Commits créés
|
||||
|
||||
- `b12081b` — `feat(memory): récolte automatique contrôlée de la mémoire (Lot E1)`
|
||||
- Domaine: parsing pur de blocs fenced `idea-memory` avec limites et erreurs isolées.
|
||||
- Application: `HarvestMemoryFromTurn` best-effort sur `TurnRole::Response`, persistance via `MemoryStore`, événements `MemorySaved` via `EventBus`.
|
||||
- Orchestrateur: harvest branché après checkpoint/handoff sur chemins de succès ask/reply, non bloquant.
|
||||
- Lifecycle: directive mémoire IdeA injectée dans le contexte convention-file.
|
||||
- App/Tauri: wiring du use case dans `AppState`.
|
||||
- Frontend: refresh du panneau mémoire sur `memorySaved`; patch test-only mock gateway `workState`.
|
||||
|
||||
- `8c7c47c` — `fix(mcp): fallback déterministe du runtime dir socket`
|
||||
- Durcit le choix du runtime dir socket MCP si `XDG_RUNTIME_DIR` est inutilisable.
|
||||
- Commit séparé car indépendant du Lot E1.
|
||||
|
||||
- `61c330a` — `merge(memory): intègre la récolte automatique contrôlée (Lot E1) dans develop`.
|
||||
|
||||
## QA verte
|
||||
|
||||
Commandes QA réelles:
|
||||
- `cargo fmt --all -- --check` OK.
|
||||
- `cargo check -p app-tauri` OK.
|
||||
- `cd frontend && npx tsc --noEmit` OK.
|
||||
- `cd frontend && npx vitest run` OK après patch test-only, `42 passed`, `405 tests`.
|
||||
- `cargo test -p domain memory_harvest -- --nocapture` OK, 14 passed.
|
||||
- `cargo test -p application --test memory_harvest -- --nocapture` OK, 5 passed.
|
||||
- `cargo test -p application --test orchestrator_service harvest -- --nocapture` OK, 4 passed.
|
||||
- `cargo test -p infrastructure --test memory_store idempotent -- --nocapture` OK, 1 passed.
|
||||
- `cargo test --workspace` brut rouge uniquement sur tests AF_UNIX/MCP bloqués par sandbox `Operation not permitted`; workspace filtré strictement sur ces tests environnementaux OK.
|
||||
|
||||
## Décisions produit/techniques
|
||||
|
||||
- Harvest strictement best-effort: jamais bloquant pour réponse, délégation, handoff ou ticket.
|
||||
- Mémoire durable seulement via directive explicite `idea-memory`, plafonnée et validée; pas de log brut, pas de live-state, pas de handoff dans ce mécanisme.
|
||||
- `title` est exigé par directive mais non persisté car l'entité `Memory` n'a pas de champ titre; accepté pour E1 afin de ne pas élargir le lot.
|
||||
- Les fichiers runtime `.ideai/*` générés pendant la session restent hors commits applicatifs.
|
||||
|
||||
## Suite probable
|
||||
|
||||
Prochains chantiers à cadrer par Architect avant implémentation:
|
||||
- persistance conversationnelle/canonical log + handoff incrémental cross-profile;
|
||||
- live-state projet persistant et séparé de la mémoire durable;
|
||||
- synchronisation documentaire architecture après les lots Work B/C/D et E1.
|
||||
@ -1,45 +0,0 @@
|
||||
---
|
||||
name: checkpoint-b2-bootstrap-applied-await-codex-reset-1430
|
||||
description: memory note checkpoint-b2-bootstrap-applied-await-codex-reset-1430
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
name: checkpoint-b2-bootstrap-applied-await-codex-reset-1430
|
||||
description: Reprise 2026-07-02 15h58 — B1-B6 tâches de fond commités+verts, AppImage fraîche buildée (NO_STRIP), prochaine étape = relance puis B7.
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Checkpoint — chantier tâches de fond de 1re classe (2026-07-02 ~15h58)
|
||||
|
||||
## Fait & COMMITÉ sur `feature/background-tasks-first-class`
|
||||
- `62915ee` fix(codex) Final canal ; `fccc1e2` chore(gitignore) target/ sous-crates.
|
||||
- **B1-B6 tâches de fond** (4 commits) : `f4a55e9` domaine (12 tests) · `c537da5` infra
|
||||
store+sink+mailbox (B2-B4, 7+6+7 tests) · `f94b542` application wake+rendezvous-as-task
|
||||
(B5-B6, agent_wake 5, orchestrator_watcher 11 passed) · `54c8ecf` app-tauri events.
|
||||
- `cargo check --workspace` + `fmt` verts. Validés QA jusqu'à B5.
|
||||
- Cadrage complet : [[background-tasks-first-class-design]]. Ancre de câblage B7 :
|
||||
[[b7-wiring-anchor-state-rs]].
|
||||
|
||||
## AppImage FRAÎCHE prête (à relancer par l'utilisateur)
|
||||
`target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage` (2026-07-02 15:57, 111 Mo),
|
||||
contient B1-B6. Buildée avec `NO_STRIP=true` (sinon linuxdeploy casse sur `.relr.dyn` —
|
||||
cf. [[appimage-build-no-strip-relr-dyn-fix]], correctif à retenir).
|
||||
|
||||
## PROCHAINES ÉTAPES (dès relance sur la nouvelle AppImage)
|
||||
1. **B7** = câbler la chaîne au runtime dans `crates/app-tauri/src/state.rs` (ancre précise
|
||||
dans [[b7-wiring-anchor-state-rs]] : `.with_background_tasks(...)` ABSENT du builder
|
||||
OrchestratorService l.1356-1453 → rendezvous-as-task dormant ; sink/bridge/wake à spawner
|
||||
via `tauri::async_runtime::spawn` ; store per-root façon `AppLiveStateProvider` ; reconcile
|
||||
greffé dans `open_project`). Déléguer à DevBackend (session fraîche recommandée).
|
||||
2. **F1-F4** front (queue depth/queued, panel tâches, badges agent cell, toasts).
|
||||
3. **QA e2e** complet (critères du cadrage) puis rebuild AppImage final (NO_STRIP=true).
|
||||
4. **B8 déféré** : coupler PTY/commandes longues (run_in_background) → BackgroundTask{Command}.
|
||||
|
||||
## Historique du blocage (résolu autrement)
|
||||
B7 a wedgé 4× en délégation DevBackend sur l'ANCIEN binaire (13:30, pré-B4/B6). D'où le
|
||||
rebuild pour déployer les fixes de canal avant de finir. Ne PAS re-tenter B7 sur l'ancien
|
||||
binaire : relancer d'abord.
|
||||
|
||||
Liens : [[background-tasks-first-class-design]], [[b7-wiring-anchor-state-rs]],
|
||||
[[appimage-build-no-strip-relr-dyn-fix]], [[mcp-e2e-findings-reply-wedge-phantom-busy]].
|
||||
@ -1,47 +0,0 @@
|
||||
---
|
||||
name: checkpoint-b7-blocked-codex-session-limit
|
||||
description: memory note checkpoint-b7-blocked-codex-session-limit
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
name: checkpoint-b7-blocked-codex-session-limit
|
||||
description: RÉSOLU 2026-07-02 — B7 (câblage runtime tâches de fond) + F1-F4 livrés, QA vert, commités ; rebuild AppImage lancé. Historique du blocage Codex conservé.
|
||||
metadata:
|
||||
type: reference
|
||||
---
|
||||
# Checkpoint — B7 + F1-F4 LIVRÉS (2026-07-02) — anciennement bloqué Codex
|
||||
|
||||
## RÉSOLUTION (à jour)
|
||||
Codex est revenu, le cycle complet a tourné via le canal inter-agent (fiable cette fois) :
|
||||
- **B7** câblé par DevBackend dans `crates/app-tauri/src/state.rs` (store per-root routé par
|
||||
project_id façon AppLiveStateProvider, `AppReconcileBackgroundTasks` reconcile boot,
|
||||
`AppWakeSessionProvider`, boucle ready→MediatedInbox→AgentWakeService via
|
||||
`tauri::async_runtime::spawn`, `.with_background_tasks(store,clock)` au builder
|
||||
OrchestratorService ~l.1858) + `commands.rs` (`reconcile_background_tasks` dans open_project).
|
||||
- **F1-F4** front par DevFrontend (workStateNormalization, ProjectWorkStatePanel, LayoutGrid
|
||||
badges Queued/Task done, ProjectsView toast, useProjectWorkState abonné aux events
|
||||
backgroundTaskChanged/agentInboxChanged/agentWakeChanged).
|
||||
- **QA vert** : app-tauri 52/52 (dont test reconcile boot dédié + 4 tests MCP périmés alignés
|
||||
au nouveau protocole : idea_reply retiré→JSON-RPC -32601, idea_ask_agent exposé=13 tools,
|
||||
rendez-vous capture Final inline), domain 224+12, application 5, infrastructure 30+,
|
||||
frontend 449. Zéro régression (les 4 tests MCP échouaient déjà à l'identique sur base @54c8ecf).
|
||||
- **Commité** (pas de push/merge sans validation user) : `e05edc6` backend (B7 + tests),
|
||||
`5d88c95` frontend. `.ideai/memory` + `.ideai/proposals` volontairement non commités.
|
||||
- **Rebuild AppImage** lancé : `NO_STRIP=true` (cf. [[appimage-build-no-strip-relr-dyn-fix]]).
|
||||
|
||||
## Réserves connues (assumées V1, = lot B8 déféré)
|
||||
- Pas de `BackgroundTaskRunner` concret dans infrastructure → le sink de complétion ne s'abonne
|
||||
pas à un runner réel ; complétion d'une commande `run_in_background` post-tour PAS testable
|
||||
e2e (le rendez-vous inter-agent B6/HeadlessRendezvous, lui, EST vivant — c'était la douleur
|
||||
principale). Boutons UI cancel/retry désactivés (pas de commande Tauri) — tooltip explicite.
|
||||
- Prochain lot naturel B8 : runner de commandes couplé PTY (crée BackgroundTask{Command} au
|
||||
spawn, pousse exit/stdout dans le sink) → active le flux run_in_background complet + cancel/retry.
|
||||
|
||||
## Historique du blocage (résolu)
|
||||
Codex était en limite de session ; les 4 workers (Architect/DevBackend/DevFrontend/QA, profil
|
||||
`664cc20c-…-dce4c09c3da4`) tous murés en même temps ; Main+Git sur `…dce3c09c0de4` libres.
|
||||
Décision user = attendre le reset (pas d'entorse Main/Git ne code). Reset survenu → cycle repris.
|
||||
|
||||
Lien : [[b7-wiring-anchor-state-rs]], [[background-tasks-first-class-design]],
|
||||
[[appimage-build-no-strip-relr-dyn-fix]], [[session-limit-handling-design]].
|
||||
@ -1,24 +0,0 @@
|
||||
---
|
||||
name: checkpoint-b8-command-runner-loop-closed
|
||||
description: memory note checkpoint-b8-command-runner-loop-closed
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# B8 — Runner de commandes + boucle sink fermée (DevBackend, 2026-07-03)
|
||||
|
||||
Base `feature/background-tasks-first-class`. Suite de [[b8-command-runner-pty-framing]]. **Build workspace vert** ; sink tests (6) + tail units (5) + reconcile B7 verts. **Non committé** (Git tranche). QA à suivre.
|
||||
|
||||
## Livré (sous-tâches 1-5)
|
||||
- **Domaine** : nouveau port `BackgroundCommandArchive { spec_for(TaskId)->Option<SpawnSpec> }` (ports.rs, exporté lib). Ajouté car le retry a besoin de la commande d'origine, qui n'est PAS un champ persisté du `BackgroundTask`. **À faire bénir par Architect** (ajout hors port figé).
|
||||
- **Infra** : `background_task.rs` → module dir (`sink.rs` déplacé verbatim, `tail.rs`, `runner.rs`).
|
||||
- `tail.rs` : `BoundedTail` ring UTF-8-safe + `bounded_tail()` + `tail_cap_bytes()` (env `IDEA_BG_TAIL_BYTES`, défaut 8 KiB, clamp [1 KiB, domaine 16 KiB]).
|
||||
- `runner.rs` : `CommandBackgroundRunner` compose `Arc<dyn PtyPort>` + `Arc<dyn Clock>`. `spawn` → pty.spawn(24x80) + worker détaché ; détection de fin = EOF du stream single-consumer ; tail lu du **scrollback** (pas du stream, robuste à la course subscribe) ; exit code via `kill()` (wait après EOF naturel) ; `cancel` = flag+Notify (la branche cancel gagne la course EOF) ; deadline→Expired via select. Implémente `BackgroundTaskRunner` + `BackgroundCommandArchive`. Émet 1 complétion/tâche, n'écrit ni store ni inbox.
|
||||
- **Application** : module `background` : `SpawnBackgroundCommand` (alloue TaskId, create Queued→save Running, runner.spawn ; si spawn KO → task Failed best-effort), `CancelBackgroundTask`, `RetryBackgroundTask` (nouveau TaskId, deadline **droppée** pour éviter l'expiry instantané ; réutilise `create_and_run`).
|
||||
- **Composition root** (state.rs ~1545) : runner + `BackgroundCompletionSink::new(store, ready_tx.clone())` + `sink.start_from_runner(runner)` DANS `tauri::async_runtime::spawn` (Handle::current requis) ; JoinHandle du drain gardé vivant via `.await`. 4 champs AppState + use cases câblés. **Boucle B2 fermée** (avant : sink/runner uniquement en tests).
|
||||
- **app-tauri** : `BackgroundTaskDto` camelCase (aplati result→exitCode/summary/tails), `parse_task_id`, commandes `spawn_background_command` (AJOUTÉE hors liste framing pour rendre la boucle atteignable/testable), `cancel_background_task`, `retry_background_task`, `list_background_tasks` — enregistrées dans invoke_handler.
|
||||
|
||||
## Écarts au cadrage (à arbitrer)
|
||||
1. **Tee PTY live (sous-tâche 6) NON câblé** : le `Broadcast` de `PortablePtyAdapter` est **single-consumer** (chaque `subscribe_output` supersede le précédent). Un tee UI re-souscrirait et **casserait la détection EOF du runner**. Un vrai tee live exige un broadcast multi-consommateur OU un port `wait/try_wait` sur PtyPort → **décision Architect** (PtyPort figé). Documenté dans `runner.rs`.
|
||||
2. **stderr_tail toujours None** : le PTY fusionne stdout/stderr → sortie fusionnée dans `stdout_tail`.
|
||||
3. Port `BackgroundCommandArchive` ajouté (voir ci-dessus).
|
||||
4. `list_background_tasks` sans `agentId` ne renvoie que les complétions non livrées du projet (le store ne sait pas énumérer les tâches ouvertes par projet).
|
||||
@ -1,46 +0,0 @@
|
||||
---
|
||||
name: checkpoint-blocked-until-appimage-030-restart
|
||||
description: memory note checkpoint-blocked-until-appimage-030-restart
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Checkpoint — blocage délégation Architect jusqu'au redémarrage AppImage 0.3.0
|
||||
|
||||
Date: 2026-06-20
|
||||
|
||||
## État atteint
|
||||
|
||||
Chantier `orchestrator-designation` terminé et intégré localement:
|
||||
- `develop` @ `9c71a5b` après commit runtime post-build.
|
||||
- Worktree propre à ce moment.
|
||||
- AppImage corrigée générée:
|
||||
`/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`
|
||||
- Artefact vérifié:
|
||||
- taille 106M
|
||||
- `--appimage-offset` = `944632`
|
||||
|
||||
## Problème live confirmé
|
||||
|
||||
Deux tentatives de délégation vers Architect ont affiché le texte dans le chat/terminal d'Architect sans le soumettre réellement.
|
||||
L'utilisateur a interrompu et confirmé: « Le message n'arrive pas jusqu'à Architecte visiblement ».
|
||||
|
||||
Ce symptôme correspond au bug live de soumission write-portal/headless delivery corrigé dans `orchestrator-designation`, mais l'application en cours tourne encore avec l'ancien AppImage. Le nouvel artefact n'est pas chargé tant qu'IdeA n'est pas relancé avec l'AppImage 0.3.0.
|
||||
|
||||
## Action effectuée
|
||||
|
||||
Architect stoppé pour éviter un terminal avec tâche fantôme.
|
||||
|
||||
## Prochain chantier prévu après redémarrage
|
||||
|
||||
Git a recommandé:
|
||||
- Prochain chantier: `feature/agent-skill-awareness`.
|
||||
- Architect doit d'abord trancher le chevauchement avec `feature/agent-skills`.
|
||||
- `fix/cold-start-delivery-race` est probablement obsolète/superseded par `feature/agent-skill-awareness`, mais à supprimer seulement après intégration ou décision Git finale.
|
||||
|
||||
## Reprise recommandée
|
||||
|
||||
1. Relancer IdeA avec:
|
||||
`/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`
|
||||
2. Reprendre par une délégation Architect:
|
||||
cadrage `agent-skill-awareness` vs `agent-skills`.
|
||||
3. Ensuite cycle normal: Git -> DevBackend -> QA -> Git.
|
||||
@ -1,88 +0,0 @@
|
||||
---
|
||||
name: checkpoint-delivery-submit-logging-fix
|
||||
description: memory note checkpoint-delivery-submit-logging-fix
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Checkpoint — hotfix livraison délégation + logs submit
|
||||
|
||||
Date: 2026-06-20
|
||||
|
||||
## Pourquoi ce checkpoint existe
|
||||
|
||||
Après le fix AppImage 0.3.0 précédent, la délégation `Main -> DevBackend` a reproduit le même symptôme que `Main -> Architect` avant redémarrage : le message de délégation apparaît dans l'input de la cellule cible, mais n'est pas soumis.
|
||||
|
||||
Le chantier `feature/agent-skill-awareness-v2` est donc suspendu tant que le canal de délégation n'est pas fiable.
|
||||
|
||||
## Branche et état
|
||||
|
||||
Branche active pendant le hotfix : `feature/agent-skill-awareness-v2`.
|
||||
|
||||
Dirty attendu hors code : fichiers runtime `.ideai/conversations/*`, `.ideai/layouts.json` produits par la session live.
|
||||
|
||||
## Changements code effectués
|
||||
|
||||
Frontend :
|
||||
- `frontend/src/features/terminals/useWritePortal.ts`
|
||||
- Logs détaillés `[write-portal]` : abonnement, attachement front, réception `delegationReady`, chunks de texte, délai avant submit, submit, ack, erreurs.
|
||||
- Fix défensif : `submitSequence: ""` est normalisée vers `"\r"` au lieu d'écrire zéro octet.
|
||||
- En cas d'erreur d'injection, arrêt du retry immédiat infini.
|
||||
- `frontend/src/adapters/terminal.ts`
|
||||
- Logs `[terminal-write]` sur writes non triviaux ou contrôles (`\r`, `\n`, bulk, etc.).
|
||||
- `frontend/src/adapters/input.ts`
|
||||
- Logs `[input-gateway]` pour `delegationDelivered` et `setFrontAttached`.
|
||||
- `frontend/src/domain/index.ts`
|
||||
- Commentaire défaut submit aligné sur ~350 ms.
|
||||
- `frontend/src/features/terminals/useWritePortal.test.tsx`
|
||||
- Test ajouté : `submitSequence: ""` doit envoyer `"\r"`.
|
||||
|
||||
Backend/application/Tauri :
|
||||
- `crates/application/src/orchestrator/service.rs`
|
||||
- `note_delegation_delivered` passe par `application::diag!` persistant.
|
||||
- `set_agent_front_attached` logge les changements d'attachement et le cas médiateur absent.
|
||||
- `crates/infrastructure/src/input/mod.rs`
|
||||
- Logs détaillés `[input-mediator]` : start turn, gate cold start, publish `DelegationReady`, choix front-owned vs headless, bind handle, front attach/detach, headless text/submit start/ok/failure.
|
||||
- Défaut headless `DEFAULT_SUBMIT_DELAY_MS` corrigé de 60 ms à 350 ms pour être aligné avec le write-portal.
|
||||
- Headless normalise aussi une submit sequence vide vers `"\r"`.
|
||||
- `crates/app-tauri/src/commands.rs`
|
||||
- Logs persistants `[pty-write]` autour de `write_terminal` avec session, bytes, contrôle sans contenu bulk.
|
||||
- Logs persistants `[delivery]` pour `delegation_delivered` et `set_front_attached`.
|
||||
|
||||
## Vérifications passées
|
||||
|
||||
- `cargo fmt --all -- --check` : OK.
|
||||
- `npx vitest run src/features/terminals/useWritePortal.test.tsx src/adapters/terminal.test.ts src/features/terminals/TerminalView.portal.test.tsx` : OK, 3 files / 20 tests.
|
||||
- `npx tsc --noEmit` : OK.
|
||||
- `cargo test -p infrastructure input --lib` : OK, 35 tests.
|
||||
- `cargo check -p app-tauri` : OK.
|
||||
- `cargo test -p application --test orchestrator_service` : OK, 45 tests (warning existant `CapturingFs::writes` unused).
|
||||
- `cargo test -p app-tauri --test orchestrator_wiring` : OK, 13 tests.
|
||||
|
||||
## Build AppImage
|
||||
|
||||
Commande Tauri standard : frontend build OK, Rust release OK, bundling Tauri KO avec `failed to run linuxdeploy` comme précédemment.
|
||||
|
||||
Contournement réussi :
|
||||
|
||||
```bash
|
||||
ARCH=x86_64 APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 \
|
||||
/tmp/appimage_extracted_02f96dbd6ecc47f616b5a57fb8b7aa60/usr/bin/appimagetool \
|
||||
--runtime-file /tmp/idea-appimage-runtime-x86_64 \
|
||||
/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA.AppDir \
|
||||
/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
|
||||
```
|
||||
|
||||
Artefact :
|
||||
- `/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`
|
||||
- taille : 106M
|
||||
- `--appimage-offset` : `944632`
|
||||
|
||||
## Reprise recommandée
|
||||
|
||||
1. Relancer IdeA avec l'AppImage ci-dessus.
|
||||
2. Reproduire une délégation simple `Main -> DevBackend` ou `Main -> Architect`.
|
||||
3. Si le message reste dans l'input sans être soumis, récupérer les traces :
|
||||
- logs persistants `application::diag!` (chemin configuré au startup, typiquement app-data logs/idea.log), chercher `[delivery]`, `[pty-write]`, `[rendezvous]`.
|
||||
- console frontend, chercher `[write-portal]`, `[terminal-write]`, `[input-gateway]`.
|
||||
- stderr si lancé depuis terminal, chercher `[input-mediator]`.
|
||||
4. Une fois délégation fiable, reprendre `feature/agent-skill-awareness-v2` depuis le cadrage Architect déjà obtenu.
|
||||
@ -1,37 +0,0 @@
|
||||
---
|
||||
name: checkpoint-finding-a-fix-built-live-validation-pending
|
||||
description: memory note checkpoint-finding-a-fix-built-live-validation-pending
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Checkpoint — Finding A : fix confirmé EN CODE + AppImage clean DÉPLOYÉE → reste la validation e2e LIVE (MAJ 2026-06-23 09:33)
|
||||
|
||||
Suite de [[mcp-e2e-findings-reply-wedge-phantom-busy]] (le défaut) et [[resume-after-appimage-rebuild-mcp-e2e]] (méthode).
|
||||
|
||||
## État du code (OK, vert)
|
||||
- Fix Finding A **mergé dans `develop @ 77e62e5`** (par-dessus feat `c5e5493`).
|
||||
- 3 lots : **Lot 1** préambule `idea_reply` impératif (`infrastructure/src/input/mod.rs` + `application/src/agent/lifecycle.rs`) ; **Lot 2 = LE fix** `with_prompt_ready_pattern("? for shortcuts")` sur le profil Claude (`application/src/agent/catalogue.rs:80`) + overlay `overlay_reference_defaults` ; **Lot 3** backstop timeout typé `TARGET_RETURNED_NO_REPLY` / env `IDEA_ASK_RENDEZVOUS_TIMEOUT_MS` (`infrastructure/src/orchestrator/mcp/server.rs`).
|
||||
- Tests lib qui PROUVENT le seed (re-passés vert le 2026-06-23) : `application::agent::catalogue::mcp_tests::claude_seed_carries_the_measured_prompt_ready_pattern` ✓ et `codex_seed_leaves_prompt_ready_pattern_empty_for_now` ✓.
|
||||
|
||||
## LEÇON D'OUTILLAGE (important, éviter de refaire l'erreur)
|
||||
**Ne PAS utiliser `strings`/`grep` sur le binaire comme oracle de présence du fix.** Le compilateur élimine/inline les littéraux uniques de `catalogue.rs` : `? for shortcuts` ET `codex --version` sont ABSENTS du binaire alors que le code et les tests les portent (les littéraux aussi présents ailleurs — `claude --version`, `.mcp.json`, `CLAUDE.md` — n'apparaissent que par co-référence). Oracle fiable = **tests** + **comportement live**, pas le grep binaire. (Une fausse alarme « build incrémental incohérent » a été levée puis invalidée ainsi.)
|
||||
|
||||
## Mise en service FAITE
|
||||
- Rebuild clean (`cargo clean -p application -p infrastructure` puis recette tauri) → artefact `…/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`.
|
||||
- **Déployé** sur `/home/anthony/Documents/IdeA_0.3.0_amd64.AppImage` (rename atomique ; SHA256 `138714473ed6a87b…` installée == artefact). Ancienne sauvegardée `…AppImage.bak-23pre`.
|
||||
- ⚠️ **L'instance IdeA qui tourne encore est l'ANCIENNE** (FUSE déjà monté). Il faut que **l'utilisateur RELANCE IdeA** pour charger le nouveau binaire — cela redémarre tous les agents, dont Main (la session courante meurt).
|
||||
|
||||
## PROCHAINE ÉTAPE après redémarrage : test e2e LIVE
|
||||
Méthode (rappel) : **NE PAS valider le système inter-agents VIA `idea_ask_agent`**. Piloter via subagents natifs / l'utilisateur. Diag EXTERNE : `ss -xp | grep idea-mcp` (ponts) ; transcripts `~/.claude/projects/<run-dir-encodé>/*.jsonl` (horodatages UTC ; reply réel = `tool_use` idea_reply ; wedge = transcript demandeur figé sur `tool_use` idea_ask_agent sans `tool_result`).
|
||||
|
||||
Scénario qui wedgeait (doit maintenant passer) :
|
||||
1. Faire déléguer **DevBackend → QA** : « réponds juste pong ».
|
||||
2. ATTENDU avec le fix : si QA répond en prose sans `idea_reply`, dans la grâce `PROMPT_READY_GRACE` le retour au prompt idle (`? for shortcuts`) déclenche `complete_without_reply` → **DevBackend reçoit `TargetReturnedNoReply` (retryable) et REPREND la main** (plus de wedge) ; `idea_workstate` QA repasse `working`→`idle`/`done` (plus de Busy fantôme). Lot 1 devrait en plus pousser QA à appeler `idea_reply` (chemin positif → DevBackend reçoit pong).
|
||||
3. Non-régression : chemin positif normal (QA appelle `idea_reply`) → demandeur reçoit le résultat, workstate→done ; livraison 1er tour à froid intacte.
|
||||
4. Calibrer `PROMPT_READY_GRACE` si la fenêtre est trop courte/longue en réel (défaut conservé).
|
||||
|
||||
## Après validation verte
|
||||
Merge `develop` déjà fait. Reste éventuelle release (0.4.0 ?) = décision utilisateur. NB : **Git est de nouveau strictement local, PLUS d'accès push** (la note `git-agent-push-access-gitea-ssh` a été corrigée en ce sens). `develop` est ~69 commits devant `origin/develop` (sync remote hors périmètre Git).
|
||||
|
||||
## Follow-ups différés (hors PR)
|
||||
Capture `prompt_ready_pattern` Codex ; généralisation merge profils de référence ; e2e délégation background (node_id None) / profils MCP défaut / observabilité UI des délégations ; durcissement doc `idea_reply` dans `CLAUDE.md` versionné (router à Git).
|
||||
@ -1,54 +0,0 @@
|
||||
---
|
||||
name: checkpoint-issue-ticket-backend-v1-done
|
||||
description: memory note checkpoint-issue-ticket-backend-v1-done
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
name: checkpoint-issue-ticket-backend-v1-done
|
||||
description: Checkpoint 2026-07-02 — backend V1 du système de tickets (T1-T5) terminé et vérifié vert sur feature/issue-ticket-system ; frontend F1-F5/F7 + QA formelle en attente du reset Codex.
|
||||
metadata:
|
||||
type: reference
|
||||
---
|
||||
# Checkpoint — système de tickets, backend V1 (T1-T5) fait & vérifié (2026-07-02)
|
||||
|
||||
Cadrage/design = [[issue-ticket-system-design]]. Branche `feature/issue-ticket-system` (base develop a9653bc).
|
||||
|
||||
## FAIT & vérifié (build + tests verts, harvesté sur disque)
|
||||
- **T1** domaine `Issue` : `crates/domain/src/issue.rs` (+ tests `domain/tests/issue.rs`),
|
||||
câblé dans `domain/src/{events.rs,ids.rs,lib.rs,ports.rs}`.
|
||||
- **T2** store FS Markdown + allocator : `crates/infrastructure/src/issues.rs`
|
||||
(`FsIssueStore`, `FsIssueNumberAllocator`, index.json, check version), tests `issue_store.rs`.
|
||||
- **T3** use cases : `crates/application/src/issues/` (Create/Read/List/Update/UpdateCarnet/
|
||||
Link/Unlink/AssignAgent, optimistic concurrency), tests `application/tests/issue_usecases.rs`.
|
||||
- **T4** surface MCP : 10 outils `idea_ticket_{create,read,list,update,update_status,
|
||||
update_priority,read_carnet,update_carnet,link,unlink}` enregistrés dans
|
||||
`infrastructure/src/orchestrator/mcp/{mod,server,tools}.rs`.
|
||||
- **T5** Tauri : `crates/app-tauri/src/tickets.rs` (commands + assign) + câblage composition-root
|
||||
`crates/app-tauri/src/state.rs` (~l.824 : FsIssueStore/FsIssueNumberAllocator/use cases/
|
||||
ticket_tool_provider). `cargo build` workspace OK ; app-tauri 47/51 tests verts.
|
||||
|
||||
## Dette pré-existante à NE PAS confondre avec régression
|
||||
4 tests app-tauri rouges (`mcp_e2e_loopback_tests::{orphan_reply_is_typed_error,
|
||||
ask_then_reply_round_trips_inline (+_codex)}`, `mcp_serve_peer_tests::handshake_then_tools_list`)
|
||||
+ `infrastructure::orchestrator_watcher::ask_request_surfaces_reply_alongside_detail` :
|
||||
tests de l'ANCIEN protocole ask/reply, échouent DÉJÀ sur `develop` vierge (prouvé par stash).
|
||||
Le fix existe sur `feature/background-tasks-first-class` (alignement QA). Résorbés quand
|
||||
background-tasks merge dans develop, ou à cherry-pick. NE PAS les compter contre les tickets.
|
||||
|
||||
## RESTE (bloqué reset Codex — les workers Architect/DevBackend/DevFrontend/QA partagent le
|
||||
profil Codex ; Main+Git libres)
|
||||
- **Frontend V1** : F1 gateway `IssueGateway` · F2 liste filtrable · F3 détail/édition
|
||||
(conflits expectedVersion) · F4 éditeur Carnet Markdown · F5 liens & assignations · F7 `#42`
|
||||
cliquable + pré-remplissage délégation. (F6 attachments = fast-follow hors V1.)
|
||||
- **QA formelle** backend+frontend (create→lire via MCP, #N séquentiel, carnet édité par agent,
|
||||
liens, assignation agent connu, optimistic concurrency conflit).
|
||||
- Puis Git commit final + rebuild AppImage (NO_STRIP=true, cf. [[appimage-build-no-strip-relr-dyn-fix]]).
|
||||
|
||||
## Note process
|
||||
Rendez-vous inter-agent timeout sur tâches LOURDES (binaire courant pré-B7) : l'agent produit
|
||||
quand même le code, harvesté sur disque par Main (build+tests réels) puis commité via Git libre.
|
||||
Confirme l'intérêt de B7/B8 (le rebuild B7 de 21:35 n'est pas encore le binaire lancé).
|
||||
|
||||
Lien : [[issue-ticket-system-design]], [[checkpoint-b7-blocked-codex-session-limit]],
|
||||
[[background-tasks-first-class-design]].
|
||||
@ -1,40 +0,0 @@
|
||||
---
|
||||
name: checkpoint-mcp-t1-t6-green-t7-fix-wrong-layer
|
||||
description: memory note checkpoint-mcp-t1-t6-green-t7-fix-wrong-layer
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
name: checkpoint-mcp-t1-t6-green-t7-fix-wrong-layer
|
||||
description: T1→T6 verts (non-régression). T7 ROUGE diagnostiqué (fix sur mauvaise couche) PUIS RE-FIX implémenté dans le working tree + vert en tests unitaires. Reste : rebuild AppImage en cours → relance IdeA → re-valider T1→T7 en live → commit Git.
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Checkpoint tests fonctionnels MCP — run a6ced819 (2026-06-24)
|
||||
|
||||
Plan via skill **mcp-rendezvous-functional-test**, Main = demandeur. Setup chauds : Main/QA/DevFrontend ; froids : Architect/DevBackend/Git.
|
||||
|
||||
## T1→T6 : VERTS sur AppImage 09:21 (aucune régression)
|
||||
T1 visibilité, T2 chaude `pong`, T3 réveil froid Git (1er tour intact), T4 background node_id None, T5 no-reply backstop (live-state purgée), T6 multi-étapes == oracle. Détails dans l'historique. NB outillage : `pgrep -af mcp-server | grep <uuid>` = FAUX positifs (le shell de mesure se matche) → filtrer `ps -eo cmd | grep 'app-tauri mcp-server'`.
|
||||
|
||||
## T7 : défaut trouvé EN LIVE puis CORRIGÉ
|
||||
**Défaut (T7e live, 621 s ≈ 600 s)** : cible en long tour unique > 600 s (transcript en croissance prouvée) coupée par un timeout PLAT `process error: agent session reply timed out`, pas d'extension. Le watchdog du fix précédent vivait côté requester (`server.rs`) mais le seam qui coupe vraiment est `application/src/orchestrator/service.rs` (`ASK_AGENT_TIMEOUT`=600s plat appliqué au drain de tour délégué, ~L1564). **Fix posé sur la mauvaise couche.**
|
||||
|
||||
**RE-FIX implémenté (subagent natif Architect→DevBackend→QA, worktree, ramené dans le main working tree ; HEAD toujours `1efe2f1`, NON committé)** :
|
||||
- Découverte clé : `ClaudeSdkSession::send().await` rend TOUS les `ReplyEvent` en bloc À LA FIN du tour (rien mid-turn) → la vivacité par-événement est inutilisable ; seul signe de vie réel = **sonde transcript** (octets `.jsonl`), comme `server.rs`.
|
||||
- Un seul `run_inactivity_watchdog` générique dans **`crates/application/src/orchestrator/rendezvous.rs`** (NOUVEAU, pur, testé), réutilisé par `service.rs` (le vrai seam) ET `server.rs` (copie privée supprimée → dé-duplication).
|
||||
- Nouveau port `AskLivenessProbe` injecté au composition root `app-tauri/state.rs` → `transcript_activity_token` (+ `with_ask_ceiling`, env `IDEA_ASK_RENDEZVOUS_CEILING_MS`, défaut 4 h). Sans injection ⇒ fallback fenêtre plate = zéro régression.
|
||||
- Issues typées : progrès<plafond → réarme ; progrès+plafond → `AppError::TargetCeilingActive` (code `RENDEZVOUS_CEILING_ACTIVE`, non-retry-aveugle) ; vrai silence → `AgentSessionError::Timeout` inchangé.
|
||||
- Défaut secondaire (busy fantôme) : `mark_target_done_best_effort` sur toutes les branches d'abandon (PTY + structuré).
|
||||
- Fichiers : application `{rendezvous.rs(new), service.rs, error.rs, lib.rs, orchestrator/mod.rs}`, infra `mcp/server.rs`, `app-tauri/state.rs` (+ les modifs infra inspector/lib pré-existantes du 1er fix).
|
||||
- **Preuve réelle (re-vérifiée par Main dans le MAIN TREE)** : `cargo test -p application --lib` 75/0 (dont progressing_target_extends_then_resolves, _hits_ceiling_distinctly, silent_target_expires_no_reply, no_probe_falls_back_to_flat_window, ceiling_active_code) ; `cargo test -p infrastructure --lib` 247/0 ; clippy 0 nouveau warning.
|
||||
|
||||
## PROCHAINE ÉTAPE (reprise après relance IdeA)
|
||||
1. **Rebuild AppImage EN COURS** (recette : `npm --prefix frontend run build` puis depuis `crates/app-tauri/` `APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 ../../frontend/node_modules/.bin/tauri build --bundles appimage` ; artefact `target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage` → remplace `/home/anthony/Documents/IdeA_0.3.0_amd64.AppImage`, backup l'ancienne). Log build : scratchpad/rebuild.log.
|
||||
2. **Utilisateur relance IdeA** (tue Main).
|
||||
3. **Reprendre le test depuis T1** (skill). Le but immédiat = **re-valider T7 EN LIVE** : déléguer une charge réelle > 600 s en un long tour (la machine est rapide : `cargo clean && cargo build --release --workspace` en boucle jusqu'à >13 min, transcript en croissance) ⇒ ATTENDU = PAS de timeout à 600 s, extension, reply final livré. Puis enchaîner T8 (parallèles), T9 (transitif A→B→C, Architect+DevBackend froids), T10 (interruption + reconcile reboot).
|
||||
4. **Si live vert : demander à Git de committer** le fix (cf. [[git-owns-commit-merge-decisions]]) ; rendez-vous MCP court marche (T2-T6), donc commit délégable à Git OU subagent natif.
|
||||
|
||||
Lié à [[rendezvous-600s-cap-too-short-heavy-tasks]], [[mcp-functional-test-plan-2026-06-24]], [[mcp-bridge-and-delegation-runtime-notes]].
|
||||
</content>
|
||||
</invoke>
|
||||
@ -1,29 +0,0 @@
|
||||
---
|
||||
name: checkpoint-mcp-tests-t1-t5-and-t5-livestate-defect
|
||||
description: memory note checkpoint-mcp-tests-t1-t5-and-t5-livestate-defect
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
name: checkpoint-mcp-tests-t1-t5-and-t5-livestate-defect
|
||||
description: Run a6ced819 — relance complète T1→T6 du test fonctionnel MCP sur AppImage 08:41 (fix T5). T5 (live-state purgée sur no-reply) VALIDÉ EN LIVE. Blocage à T7 = défaut plafond 600s connu, non corrigé.
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Checkpoint tests fonctionnels MCP — run a6ced819 (2026-06-24, relance depuis T1)
|
||||
|
||||
Binaire validé : **AppImage 2026-06-24 08:41:30** (fix live-state no-reply), process en cours = cette AppImage, git HEAD `1efe2f1`. Plan via skill **mcp-rendezvous-functional-test** (Main = demandeur). Voir [[mcp-functional-test-plan-2026-06-24]], [[rendezvous-600s-cap-too-short-heavy-tasks]], [[backstop-fires-on-intra-task-turn-rootcause]].
|
||||
|
||||
## Résultats de la relance T1→T6 (tous ✅)
|
||||
- **T1** visibilité outils ✅ — 3 requesters chauds (Main, QA, DevFrontend) chacun pont ESTAB + 2 mcp-server ; froids (Architect, DevBackend, Git) 0 process.
|
||||
- **T2** cible chaude (QA) ✅ — `pong` inline borné, workstate `done`, pas de busy fantôme.
|
||||
- **T3** réveil à froid (Git) ✅ — nouveau pont (26012/26016), 1er tour `[IdeA·tâche…]` `parentUuid:null` intact, `delivered`, `pong-cold`.
|
||||
- **T4** background node_id None (Git hors layouts.json) ✅ — `bg-step-ok`, multi-`delivered`, pont stable sans dup.
|
||||
- **T5** no-reply backstop ✅ **VALIDÉ EN LIVE (le fix marche)** — Main libéré borné avec `TargetReturnedNoReply` (« returned to its prompt without calling idea_reply », retryable) ET **QA `status:"done"` purgée** (plus de busy fantôme `working`). Défaut historique #1 fermé.
|
||||
- **T6** multi-étapes (QA lit fichier + `find` puis reply) ✅ — pas de libération prématurée, reply réel `header=… ; rs_count=55` (concorde avec `find` indépendant). Piège turn-watcher non déclenché.
|
||||
|
||||
## Blocage actuel : T7 (NON lancé — défaut connu non corrigé)
|
||||
T7 = tâche lourde > plafond 600s. C'est le finding [[rendezvous-600s-cap-too-short-heavy-tasks]] : dépassement du plafond `IDEA_ASK_RENDEZVOUS_TIMEOUT_MS` (défaut 600000) → faux `-32001` + canal de report mort (idea_reply final non livrable), alors que la cible travaille et finit sur la branche. Les pistes (extension sur signe de vie / message « cible active, plafond atteint » distinct du retryable / plafond configurable / pas de cascade) sont **à cadrer Architect, pas encore implémentées**. Lancer T7 en live = figer Main ~10 min pour re-confirmer un défaut déjà documenté.
|
||||
|
||||
## Prochaine étape (décision utilisateur en attente)
|
||||
Trois options sur T7 : (a) le lancer quand même pour re-confirmer (wedge ~10 min) ; (b) ouvrir le cycle de fix du plafond maintenant (Architect→Git→DevBackend→QA, rebuild, reprise T1) ; (c) sauter T7 et continuer T8 (parallèles), T9 (transitif A→B→C), T10 (interruption + reconcile reboot) qui ne dépendent pas du plafond. Architect/DevBackend restent froids pour T9.
|
||||
@ -1,98 +0,0 @@
|
||||
---
|
||||
name: checkpoint-orchestrator-designation-appimage-build
|
||||
description: memory note checkpoint-orchestrator-designation-appimage-build
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Checkpoint — AppImage rebuild après orchestrator-designation
|
||||
|
||||
Date: 2026-06-20
|
||||
|
||||
## État Git avant build
|
||||
|
||||
Git avait clôturé `feature/orchestrator-designation`:
|
||||
- Commits atomiques créés:
|
||||
- `287681c feat(orchestrator): ...`
|
||||
- `e462136 feat(terminals): ...`
|
||||
- `09f5362 docs: ...`
|
||||
- `5ef001e chore(wip): ...`
|
||||
- Merge local dans `develop`: `55d887f merge(orchestrator): intègre le chantier orchestrator-designation dans develop`.
|
||||
- Branche `feature/orchestrator-designation` supprimée.
|
||||
- Worktree propre à ce moment-là.
|
||||
|
||||
## Rebuild tenté
|
||||
|
||||
Commande initiale:
|
||||
|
||||
```bash
|
||||
npm --prefix frontend run build && \
|
||||
cd crates/app-tauri && \
|
||||
APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 ../../frontend/node_modules/.bin/tauri build --bundles appimage
|
||||
```
|
||||
|
||||
Résultat:
|
||||
- Frontend build OK.
|
||||
- Rust release build OK: `/home/anthony/Documents/Projects/IdeA/target/release/app-tauri`.
|
||||
- AppDir généré: `/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA.AppDir`.
|
||||
- Bundling Tauri KO: `failed to run linuxdeploy`.
|
||||
|
||||
## Contournement réussi
|
||||
|
||||
`appimagetool` extrait existait dans:
|
||||
|
||||
```text
|
||||
/tmp/appimage_extracted_02f96dbd6ecc47f616b5a57fb8b7aa60/usr/bin/appimagetool
|
||||
```
|
||||
|
||||
L'appel direct à appimagetool échouait car réseau restreint:
|
||||
|
||||
```text
|
||||
Failed to download runtime ... pass it to appimagetool with --runtime-file
|
||||
```
|
||||
|
||||
Runtime extrait depuis l'ancienne AppImage locale:
|
||||
|
||||
```bash
|
||||
/home/anthony/Documents/IdeA_0.2.0_amd64.AppImage --appimage-offset
|
||||
# 944632
|
||||
|
||||
dd if=/home/anthony/Documents/IdeA_0.2.0_amd64.AppImage \
|
||||
of=/tmp/idea-appimage-runtime-x86_64 \
|
||||
bs=1 count=944632 status=none
|
||||
chmod +x /tmp/idea-appimage-runtime-x86_64
|
||||
```
|
||||
|
||||
Commande finale réussie:
|
||||
|
||||
```bash
|
||||
ARCH=x86_64 APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 \
|
||||
/tmp/appimage_extracted_02f96dbd6ecc47f616b5a57fb8b7aa60/usr/bin/appimagetool \
|
||||
--runtime-file /tmp/idea-appimage-runtime-x86_64 \
|
||||
/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA.AppDir \
|
||||
/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
|
||||
```
|
||||
|
||||
Artefact produit:
|
||||
|
||||
```text
|
||||
/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
|
||||
Taille: 106M
|
||||
--appimage-offset: 944632
|
||||
```
|
||||
|
||||
## État Git après build
|
||||
|
||||
Le build/la session a laissé du runtime dirty:
|
||||
|
||||
```text
|
||||
## develop...origin/develop [ahead 8]
|
||||
M .ideai/conversations/6bc594e8-a37c-0dbd-1de6-6e3b73002cb4/handoff.md
|
||||
M .ideai/conversations/6bc594e8-a37c-0dbd-1de6-6e3b73002cb4/log.jsonl
|
||||
M .ideai/layouts.json
|
||||
```
|
||||
|
||||
Ne pas nettoyer arbitrairement. Demander à Git de décider si ces fichiers runtime doivent être commités/ignorés au prochain passage.
|
||||
|
||||
## Important live
|
||||
|
||||
L'AppImage en cours d'exécution ne charge pas automatiquement ce nouvel artefact. Pour utiliser les correctifs d'orchestration/write-portal, lancer l'artefact 0.3.0 produit ci-dessus ou remplacer l'AppImage installée hors sandbox si nécessaire.
|
||||
@ -1,54 +0,0 @@
|
||||
---
|
||||
name: checkpoint-orchestrator-designation-backend-compile-fix
|
||||
description: memory note checkpoint-orchestrator-designation-backend-compile-fix
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Checkpoint — orchestrator-designation backend compile fix
|
||||
|
||||
Date: 2026-06-20
|
||||
|
||||
## Branche
|
||||
|
||||
`feature/orchestrator-designation`.
|
||||
|
||||
## Décision Git
|
||||
|
||||
Finir le chantier courant sur cette branche. Pas de stash, pas de switch. Après tests verts ou résidu qualifié: retour Git pour commits atomiques puis merge local vers `develop`.
|
||||
|
||||
## Incident live
|
||||
|
||||
La délégation vers Architect a été affichée dans son chat mais non soumise. Architect a été stoppé. Symptôme cohérent avec l'AppImage live qui n'intègre pas encore les correctifs WIP write-portal/headless delivery.
|
||||
|
||||
## Vérifications Main avant correction DevBackend
|
||||
|
||||
Verts:
|
||||
- `cargo test -p infrastructure input --lib`: 35 passed.
|
||||
- `cargo test -p application --test orchestrator_service`: 45 passed.
|
||||
- `cd frontend && npx vitest run`: 41 files, 384 tests passed.
|
||||
- `cd frontend && npx tsc --noEmit`: OK.
|
||||
|
||||
Rouge initial:
|
||||
- `cargo test --workspace` ne compilait pas `crates/application/src/orchestrator/context_guard.rs`:
|
||||
- `may_write_directly` appelé avec 2 args au lieu de 3 (`OrchestratorDesignation` manquant).
|
||||
- mauvais champ `orchestrator` mis sur `ManifestEntry` au lieu de `AgentManifest`.
|
||||
- init `AgentManifest` sans `orchestrator`.
|
||||
|
||||
## Correction DevBackend
|
||||
|
||||
DevBackend a modifié `crates/application/src/orchestrator/context_guard.rs`:
|
||||
- `ProposeContext` charge `AgentManifest`, récupère `manifest.orchestrator_designation()`, puis appelle `may_write_directly(requester, &GuardedResource::ProjectContext, &designation)`.
|
||||
- Le `FileGuard` reste un verrou, pas le propriétaire de l'autorisation.
|
||||
- Tests locaux adaptés à `AgentManifest { version, entries, orchestrator }`.
|
||||
|
||||
Validations DevBackend:
|
||||
- `cargo fmt --all && cargo test -p application --test orchestrator_service`: OK, 45 passed.
|
||||
- `cargo test -p application`: OK.
|
||||
- `cargo test --workspace`: compile maintenant plus loin mais échoue dans `app-tauri` sur tests loopback Unix socket sous sandbox (`PermissionDenied`/`Operation not permitted` lors du bind `/run/user/1000/idea-mcp/*.sock`).
|
||||
|
||||
## Prochaine étape
|
||||
|
||||
QA doit qualifier le résidu app-tauri:
|
||||
- confirmer que les suites métier/orchestration sont vertes,
|
||||
- confirmer si les échecs app-tauri sont environnement/sandbox et non régression,
|
||||
- proposer la commande de validation acceptable ou le besoin de correction test/env.
|
||||
@ -1,42 +0,0 @@
|
||||
---
|
||||
name: checkpoint-orchestrator-designation-qa-verdict
|
||||
description: memory note checkpoint-orchestrator-designation-qa-verdict
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Checkpoint — QA verdict orchestrator-designation
|
||||
|
||||
Date: 2026-06-20
|
||||
|
||||
## Branche
|
||||
|
||||
`feature/orchestrator-designation`.
|
||||
|
||||
## Verdict QA
|
||||
|
||||
Chantier validable sous contrainte d'environnement. Pas de régression fonctionnelle liée à `context_guard.rs`.
|
||||
|
||||
## Commandes vertes qui font foi
|
||||
|
||||
- `cargo fmt --all -- --check`: OK.
|
||||
- `cargo test -p application --test orchestrator_service`: OK, 45 passed.
|
||||
- `cargo test -p application`: OK, suite application complète verte, incluant les tests context guard orchestrateur/proposition.
|
||||
- `cargo test -p infrastructure input --lib`: OK, 35 passed.
|
||||
- `cd frontend && npx vitest run`: OK, 41 files / 384 tests passed.
|
||||
- `cd frontend && npx tsc --noEmit`: OK.
|
||||
|
||||
## Résidu app-tauri
|
||||
|
||||
- `cargo test -p app-tauri --lib`: rouge, 39 passed / 8 failed.
|
||||
- `cargo test --workspace`: rouge sur le même bloc app-tauri.
|
||||
|
||||
Échecs exacts: tests loopback Unix socket:
|
||||
- `mcp_bridge::tests::end_to_end_over_real_loopback`
|
||||
- `state::bind_endpoint_d1_tests::rebind_after_corpse_socket_succeeds`
|
||||
- `state::mcp_e2e_loopback_tests::*`
|
||||
|
||||
Cause qualifiée par QA: contrainte environnement/sandbox. Une sonde Node minimale échoue aussi à `listen()` sur Unix socket avec `EPERM` sous `/run/user/1000` et sous `/tmp`. Donc les tests qui exigent un vrai socket Unix ne sont pas exécutables dans ce sandbox.
|
||||
|
||||
## Prochaine étape
|
||||
|
||||
Retour à Git pour commits atomiques sur `feature/orchestrator-designation`, puis décision de merge local vers `develop` selon sa stratégie. Aucun push.
|
||||
@ -1,38 +0,0 @@
|
||||
---
|
||||
name: checkpoint-orchestrator-designation-restart
|
||||
description: memory note checkpoint-orchestrator-designation-restart
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Checkpoint — reprise chantier orchestrator-designation
|
||||
|
||||
Date: 2026-06-20
|
||||
|
||||
## Situation
|
||||
|
||||
L'utilisateur a demandé de terminer les chantiers ouverts. Main a repris le cycle proprement.
|
||||
|
||||
## Décision Git obtenue
|
||||
|
||||
Git a inspecté l'état local et décidé:
|
||||
|
||||
- Branche courante: `feature/orchestrator-designation`.
|
||||
- Worktree dirty important mais analysé comme mono-thème: chantier orchestrateur/designation + diagnostic inter-agents.
|
||||
- Ne pas stash, ne pas switch, ne pas ouvrir une nouvelle branche maintenant.
|
||||
- Premier chantier à fermer: `orchestrator-designation` sur la branche actuelle.
|
||||
- Après stabilisation + tests verts: retour à Git pour commits atomiques puis merge local vers `develop`.
|
||||
- Ensuite seulement ouvrir des branches dédiées pour les autres chantiers.
|
||||
|
||||
## Incident de délégation
|
||||
|
||||
Main a tenté de demander à Architect de cadrer `orchestrator-designation` via `idea_ask_agent`.
|
||||
L'utilisateur a interrompu et signalé qu'Architect était bloqué avec le texte de la tâche affiché dans son chat mais non envoyé.
|
||||
|
||||
Interprétation: symptôme cohérent avec les problèmes actuels de write portal / soumission physique PTY / délégation visible-background. Ne pas empiler de nouvelles délégations tant que cette zone n'est pas stabilisée.
|
||||
|
||||
## Prochaine reprise recommandée
|
||||
|
||||
1. Nettoyer/arrêter l'agent Architect bloqué si nécessaire.
|
||||
2. Reprendre le chantier courant localement en lecture seule pour identifier exactement les changements WIP liés à la soumission de délégations.
|
||||
3. Comme Main ne code pas, utiliser la délégation seulement vers un agent dont la soumission est confirmée fonctionnelle, ou lancer les agents en visible et vérifier qu'ils reçoivent réellement la tâche.
|
||||
4. Priorité technique immédiate: fermer `orchestrator-designation`, car la délégation inter-agents fiable conditionne tous les autres chantiers.
|
||||
@ -1,38 +0,0 @@
|
||||
---
|
||||
name: checkpoint-rendezvous-redesign-devbackend-todo
|
||||
description: memory note checkpoint-rendezvous-redesign-devbackend-todo
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Checkpoint — Backstop no-reply : 1ère validation live ÉCHOUÉE → cause racine corrigée → RE-VALIDATION LIVE EN ATTENTE (MAJ 2026-06-23 ~19:40)
|
||||
|
||||
## Résultat du 1er test live (AppImage 0.3.0 du commit e87c05f) : ÉCHEC reproduisant le wedge
|
||||
Scénario joué : DevBackend→QA `ping (test backstop)`, QA répond `pong` EN PROSE sans `idea_reply`.
|
||||
- QA a bien émis un vrai `turn_duration durationMs=2218` (transcript, ts 17:23:40.161Z).
|
||||
- MAIS `[turn-watcher] turn_ended` JAMAIS émis (`grep -c turn_ended` sur tout le log = **0**) → DevBackend resté coincé → rendez-vous Main→DevBackend a timeout 600s (MCP error -32001).
|
||||
|
||||
## CAUSE RACINE (prouvée) — encodage du slug projet Claude faux
|
||||
Traces `[turn-watcher] arm` : toutes `conversation=<none>` + `baseline … count=0`. Le dossier transcript calculé n'existait pas :
|
||||
- calculé (faux) : `…/-home-…-IdeA-.ideai-run-<uuid>` (point conservé) → `ls` = absent
|
||||
- réel (disque) : `…/-home-…-IdeA--ideai-run-<uuid>` (DOUBLE tiret)
|
||||
`encode_cwd` (crates/infrastructure/src/inspector/claude_paths.rs) ne remplaçait que `/`/`\\` et gardait le `.`. Claude Code encode `replace(/[^a-zA-Z0-9]/g,'-')`. Dir introuvable → conversation non résolue → baseline 0 → `turn_duration` jamais vu → backstop mort.
|
||||
Log de référence : `/home/anthony/.local/share/app.idea.ide/logs/idea.log`.
|
||||
|
||||
## FIX LIVRÉ par DevBackend (NON commité — Git tranche)
|
||||
- `encode_cwd` : `.map(|c| if c.is_ascii_alphanumeric() { c } else { '-' })` (algo exact Claude Code). `/IdeA/.ideai/run` → `-IdeA--ideai-run`.
|
||||
- Test non-régression ajouté `encode_cwd_encodes_dot_in_run_dir_to_double_dash` (PASS). Test Windows maj `C:\\Users\\me`→`C--Users-me`.
|
||||
- DevBackend précise : `count_turn_ends` agrège déjà tous les `.jsonl` du dossier ⇒ pas besoin de choisir un .jsonl ; `conversation=<none>` à l'armement est normal et sans impact une fois le dir correct.
|
||||
|
||||
## QA PRÉ-VALIDATION : VERTE
|
||||
`cargo test --workspace` = **1616 passed, 0 failed** ; `cargo clippy --workspace --all-targets` = 0 erreur. Nouveau test + 5 tests turn-watcher tous PASS.
|
||||
|
||||
## EN COURS : rebuild AppImage (par Main, perms project-root OK)
|
||||
Recette : `npm --prefix frontend run build` puis depuis `crates/app-tauri/` `APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 ../../frontend/node_modules/.bin/tauri build --bundles appimage`. Logs scratchpad fe-build.log / appimage-build.log. Sortie : `/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`.
|
||||
|
||||
## SEUL RESTE À FAIRE = RE-VALIDATION LIVE (garde-fou Git : pas de merge sans wedge prouvé levé EN LIVE)
|
||||
1. Utilisateur remplace l'AppImage installée par la nouvelle + relance IdeA (coupe la session).
|
||||
2. Session fraîche : rejouer DevBackend→QA pong-sans-`idea_reply`. ATTENDU cette fois : trace `arm … dir=…IdeA--ideai-run-… conversation=…` sur dossier EXISTANT + baseline NON nulle + `[turn-watcher] turn_duration detected … -> turn_ended` ⇒ libération du demandeur ~grâce (≈2s) avec résultat no-reply synthétique, et non-régression du chemin propre `idea_reply`.
|
||||
3. Si VERT → demander à Git d'amender/committer le fix sur `feature/rendezvous-no-reply-backstop` puis décider du merge develop. Si KO → relayer trace réelle à DevBackend.
|
||||
|
||||
## Trou produit confirmé (hors scope, à planifier)
|
||||
Au reboot, `.ideai/live-state.json` non réconcilié : agents restent `working` fantôme (process morts). Fichier file-guardé, `idea_workstate_set` = self only, aucun reset cross-agent. Manque : réconciliation au boot OU outil orchestrateur de reset.
|
||||
@ -1,34 +0,0 @@
|
||||
---
|
||||
name: checkpoint-t1-wake-delivery-bug-fixed-rebuild-pending
|
||||
description: memory note checkpoint-t1-wake-delivery-bug-fixed-rebuild-pending
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
name: checkpoint-t1-wake-delivery-bug-fixed-rebuild-pending
|
||||
description: Ticket #1 — T1 VERT live. T3 root cause = tâches de fond jamais projetées dans work-state ; fix BE+FE livré unit-green ; rebuild AppImage en cours ; reste re-QA live T3 + T2 reboot, puis merge.
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Checkpoint ticket #1 — état au 2026-07-03
|
||||
|
||||
## T1 — VERT (validé live QA)
|
||||
Wake auto du propriétaire à la complétion + `completionDelivered: true` prouvés dans le store (`.ideai/background-tasks/<owner>.json`, task `02aa2493`). Fixes portant T1 (unit-green, NON commités) : wake.rs:119 (mark_completion_delivered dès session.send accepté), structured.rs:121 (drain_reply_stream_with_readiness), agent_wake.rs:504 (régression), + itér.1 MediatedInbox enqueue FIFO sans busy.
|
||||
Note : `idea_workstate_read` n'expose PAS les BackgroundTasks — lire le store JSON.
|
||||
|
||||
## T3 — root cause trouvée + fix livré (unit-green, NON commité)
|
||||
Défaut live : aucun bouton Cancel/Retry dans le panneau Work. Cause = le DTO `AgentWorkState` ne portait pas les tâches de fond et `GetProjectWorkState` n'avait pas de dépendance BackgroundTaskStore → `agent.backgroundTasks` toujours vide en live → section masquée (ProjectWorkStatePanel.tsx:638). Front déjà câblé, seule la projection backend manquait. Vitest verts en trompe-l'œil (payload mocké).
|
||||
Cadrage Architect : mémoire `workstate-background-tasks-projection-fix` (Option A — étendre le read-model unique, best-effort, aucun nouveau port).
|
||||
Livré :
|
||||
- BE (DevBackend) : VO `AgentBackgroundTaskState` + champ `background_tasks` sur AgentWorkState + builder `with_background_tasks` + projection union open/undelivered best-effort (workstate/mod.rs) ; DTO Tauri backgroundTasks (dto.rs) ; wiring state.rs. Tests : `cargo test -p application` 24 passed (workstate.rs), `-p app-tauri` vert, build workspace OK.
|
||||
- FE (DevFrontend) : mapping queued/waiting→pending explicité, test sur vrai shape backend, + correctif tri (finishedAtMs jamais émis → bascule sur updatedAtMs). vitest 460/460, build OK. Verdict : `tickets-t3-frontend-validation-verdict`.
|
||||
- Dette de contrat tracée en ticket #5 (summary non affiché, owner/project inutiles). Low.
|
||||
|
||||
## RESTE À FAIRE (ordre)
|
||||
1. Rebuild AppImage `NO_STRIP=true` — EN COURS (background bixa34tht). Voir [[appimage-build-no-strip-relr-dyn-fix]].
|
||||
2. Utilisateur relance l'AppImage.
|
||||
3. QA re-passe T3 LIVE : T3-a apparition running + Cancel actif ; T3-b Cancel agit → cancelled + Retry actif ; T3-c Retry → nouvelle tâche running ; T3-d borne livraison (tâche livrée disparaît = conforme V1, PAS un bug) ; T3-e isolation par agent ; T3-f non-régression live/busy/tickets. Détail dans cadrage Architect.
|
||||
4. T2 — reconcile après reboot (fin AVANT wake), protocole MANUEL, coordination reboot utilisateur.
|
||||
5. Si T1+T2+T3 verts → Git commit de TOUS les fix (T1 + T3 BE/FE) + merge feature/background-tasks-first-class → develop (résorbe aussi 4 tests protocole MCP périmés rouges sur develop).
|
||||
|
||||
Liens : [[workstate-background-tasks-projection-fix]], [[tickets-t3-frontend-validation-verdict]], [[b8-in-app-trigger-run-in-background]], [[background-tasks-first-class-design]].
|
||||
@ -1,34 +0,0 @@
|
||||
---
|
||||
name: checkpoint-work-tab-blank-fix
|
||||
description: memory note checkpoint-work-tab-blank-fix
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Checkpoint — Fix onglet Work vide
|
||||
|
||||
Date: 2026-06-21
|
||||
|
||||
## État final
|
||||
|
||||
Correctif frontend de l'onglet Work vide terminé, validé QA (VERT) et mergé localement dans `develop`.
|
||||
|
||||
- `develop` @ `a66881d` — merge local `--no-ff` du fix.
|
||||
- Commit de feature intégré : `3e1e553` (anciennement `9d2f186`, message amendé pour retirer le marqueur `(WIP, QA en attente)`).
|
||||
- Branche `fix/work-tab-blank-page` supprimée après merge.
|
||||
- Aucun push, aucune PR. `develop` en avance de 45 commits sur `origin/develop` (local-only).
|
||||
|
||||
## Contenu du fix
|
||||
|
||||
Normalisation défensive du work-state (`frontend/src/adapters/workStateNormalization.ts` nouveau) + adaptation panneau/mock/tests, pour qu'un work-state partiel/inattendu ne rende plus une page entièrement vide. 5 fichiers, +259/-47.
|
||||
|
||||
## QA verte (sortie réelle)
|
||||
|
||||
- `cd frontend && npx tsc --noEmit` → exit 0.
|
||||
- `cd frontend && npx vitest run` → 42 fichiers / 407 tests passed, exit 0.
|
||||
|
||||
## Branches ouvertes restantes (non mergées dans develop)
|
||||
|
||||
À cadrer/arbitrer avant intégration :
|
||||
- `feature/agent-skills` @ `ef101db` — domaine skills agent + use cases + FS store + injection LaunchAgent (L12).
|
||||
- `feature/agent-skill-awareness` @ `5be8987` — manifeste skills + outil MCP `idea_skill_read` + brief « capacités IdeA » dans contexte agent ; contient aussi un fix input cold-start (`e93a2c1`).
|
||||
- `fix/cold-start-delivery-race` @ `9590eac` — fix livraison délégation cold-start ; branche basée sur d'anciens commits release (0.1.0/0.2.0), potentiellement redondante avec `e93a2c1` de skill-awareness → vérifier avant merge.
|
||||
@ -1,64 +0,0 @@
|
||||
---
|
||||
name: checkpoint-workstate-controlled-actions-lot-d
|
||||
description: memory note checkpoint-workstate-controlled-actions-lot-d
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Checkpoint — Workstate controlled actions Lot D
|
||||
|
||||
Date: 2026-06-20
|
||||
|
||||
## État final
|
||||
|
||||
Lot D `workstate controlled actions` terminé, validé QA et mergé localement dans `develop`.
|
||||
|
||||
Branche finale:
|
||||
- `develop` @ `c1e99d1` — merge local `feature/workstate-controlled-actions`.
|
||||
- `feature/workstate-controlled-actions` conservée.
|
||||
- Aucun push, aucune branche supprimée.
|
||||
- Working tree propre après décision Git.
|
||||
|
||||
## Commits créés
|
||||
|
||||
- `3408c96` — `feat(workstate): actions contrôlées sur le work-state (Lot D backend)`
|
||||
- Use cases agent-level `AttachLiveAgent` et `StopLiveAgent`.
|
||||
- Commandes Tauri `attach_live_agent` et `stop_live_agent`.
|
||||
- Attach rebind PTY/structured sans spawn; stop PTY/structured.
|
||||
- DTO camelCase et wiring AppState/lib.
|
||||
|
||||
- `1c6441b` — `feat(workstate): UI des actions contrôlées (Lot D frontend)`
|
||||
- Port/adaptateur agent alignés sur le nouveau contrat attach + stop.
|
||||
- Panneau Work: Open, Attach, Stop, View conversation, Copy summary.
|
||||
- Work n'appelle pas `launchAgent`; Stop passe par `stopLiveAgent`; View/Copy n'utilisent que les previews Lot C.
|
||||
|
||||
- `0976648` — `chore(wip): état runtime .ideai (flux conversation live)`
|
||||
- Runtime isolé des commits feature.
|
||||
|
||||
- `c1e99d1` — merge local dans `develop`.
|
||||
|
||||
## QA verte
|
||||
|
||||
Commandes QA/Git validées:
|
||||
- `cargo fmt --all -- --check` OK.
|
||||
- `cargo test -p application --test workstate_actions` OK, 7 passed.
|
||||
- `cargo test -p application --test workstate` OK, 21 passed.
|
||||
- `cargo test -p app-tauri --test dto_agents` OK, 25 passed.
|
||||
- `cargo test -p app-tauri --test list_live_agents_r0b` OK, 5 passed.
|
||||
- `cargo check -p app-tauri` OK.
|
||||
- `cd frontend && npx vitest run src/features/workstate/workstate.test.tsx src/features/projects/projects.test.tsx` OK, 25 tests.
|
||||
- `cd frontend && npx vitest run src/adapters/agent.test.ts` OK, 8 tests.
|
||||
- `cd frontend && npx vitest run src/features/layout/singletonAgent.test.tsx src/features/layout/agentAlreadyRunning.test.tsx` OK, 9 tests.
|
||||
- `cd frontend && npx tsc --noEmit` OK.
|
||||
|
||||
Warnings restants uniquement côté Vite sur options `esbuild` dépréciées/ignorées au profit de `oxc`, non bloquants.
|
||||
|
||||
## Décisions produit/techniques
|
||||
|
||||
- Actions Lot D opèrent seulement sur l'état existant; pas de lancement d'agent neuf depuis Work.
|
||||
- Attach ne crée ni session ni cellule; cible déterministe = cellule visible vide côté UI.
|
||||
- Stop ne supprime ni agent, ni tickets, ni handoff/conversation summary.
|
||||
- View/Copy restent limités aux previews bornées Lot C; aucun log brut exposé.
|
||||
|
||||
## Suite probable
|
||||
|
||||
La quadrilogie Work A/B/C/D est intégrée. Prochains chantiers restants à cadrer: persistance conversationnelle/cross-profile plus profonde, mise à jour automatique mémoire/contexte pendant la vie des agents, ou synchronisation documentaire architecture selon priorité Architect/Main.
|
||||
@ -1,60 +0,0 @@
|
||||
---
|
||||
name: checkpoint-workstate-conversation-summaries-lot-c
|
||||
description: memory note checkpoint-workstate-conversation-summaries-lot-c
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Checkpoint — Workstate conversation summaries Lot C
|
||||
|
||||
Date: 2026-06-20
|
||||
|
||||
## État final
|
||||
|
||||
Lot C `workstate conversation summaries` terminé, validé QA et mergé localement dans `develop`.
|
||||
|
||||
Branche finale:
|
||||
- `develop` @ `6e1ba7e` — merge local `feature/workstate-conversation-summaries`.
|
||||
- `feature/workstate-conversation-summaries` conservée.
|
||||
- Aucun push, aucune branche supprimée.
|
||||
- Working tree propre après décision Git.
|
||||
|
||||
## Commits créés
|
||||
|
||||
- `e9edadc` — `feat(workstate): résumés de conversation dans le read-model (Lot C backend)`
|
||||
- `ProjectWorkState.conversations` top-level.
|
||||
- Résumés best-effort depuis `HandoffStore`, fallback `ConversationLog::last(3)`.
|
||||
- Déduplication des conversation ids issus des tickets, ordre first-seen.
|
||||
- DTO camelCase et câblage Tauri.
|
||||
|
||||
- `c50622e` — `feat(workstate): UI des résumés de conversation (Lot C frontend)`
|
||||
- Types TS `ConversationWorkSummary` et previews.
|
||||
- Mock normalise `conversations: []`.
|
||||
- Panneau Work joint `tickets[].conversationId` vers `conversations[]` et affiche badge + preview compacte.
|
||||
|
||||
- `78500d8` — `chore(wip): état runtime .ideai (flux conversation live)`
|
||||
- Runtime isolé des commits feature.
|
||||
|
||||
- `6e1ba7e` — merge local dans `develop`.
|
||||
|
||||
## QA verte
|
||||
|
||||
Commandes QA finales validées:
|
||||
- `cargo fmt --all -- --check` OK.
|
||||
- `cargo test -p application --test workstate` OK, 21 passed, aucun warning Rust.
|
||||
- `cargo test -p app-tauri --test dto_agents` OK, 21 passed.
|
||||
- `cargo check -p app-tauri` OK.
|
||||
- `cd frontend && npx vitest run src/features/workstate/workstate.test.tsx src/features/projects/projects.test.tsx` OK, 2 files / 19 tests.
|
||||
- `cd frontend && npx tsc --noEmit` OK.
|
||||
|
||||
Warnings restants uniquement côté Vite sur options `esbuild` dépréciées/ignorées au profit de `oxc`, non bloquants.
|
||||
|
||||
## Décisions produit/techniques
|
||||
|
||||
- Source primaire: handoff conversationnel existant.
|
||||
- Fallback: derniers tours bornés du log, jamais le log brut complet.
|
||||
- Read-only et best-effort: les erreurs de preview ne bloquent pas `live/busy/tickets`.
|
||||
- Pas de nouvelle persistance, pas de mutation/réparation, pas de nouvelle action UX.
|
||||
|
||||
## Suite probable
|
||||
|
||||
Le prochain lot logique est Lot D: actions UX read/write contrôlées autour du panneau Work (ouvrir/rattacher cellule, voir conversation, arrêter agent, éventuellement copier résumé), à cadrer par Architect avant implémentation.
|
||||
@ -1,62 +0,0 @@
|
||||
---
|
||||
name: checkpoint-workstate-delegation-queue-lot-b
|
||||
description: memory note checkpoint-workstate-delegation-queue-lot-b
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Checkpoint — Workstate delegation/queue snapshot Lot B
|
||||
|
||||
Date: 2026-06-20
|
||||
|
||||
## État final
|
||||
|
||||
Lot B `workstate delegation/queue snapshot` terminé, validé QA et mergé localement dans `develop`.
|
||||
|
||||
Branche finale:
|
||||
- `develop` @ `64c2c14` — merge local `feature/workstate-delegation-queue`.
|
||||
- `feature/workstate-delegation-queue` conservée.
|
||||
- Aucun push, aucune branche supprimée.
|
||||
- Working tree propre après décision Git.
|
||||
|
||||
## Commits créés
|
||||
|
||||
- `cc7d99a` — `feat(workstate): snapshot des délégations en file par agent (Lot B backend)`
|
||||
- `QueuedTicketSnapshot` + port read-only `AgentQueueSnapshot`.
|
||||
- Impl `InMemoryMailbox` snapshot FIFO sans cloner les senders.
|
||||
- `GetProjectWorkState.agents[].tickets` avec statut dérivé `inProgress/queued`, source `human/agent`, preview bornée.
|
||||
- DTO Tauri camelCase et wiring `AppState` avec le même mailbox partagé en deux ports.
|
||||
|
||||
- `c600604` — `feat(workstate): UI des délégations en file par agent (Lot B frontend)`
|
||||
- Types TS `AgentTicketState`, `TicketWorkStatus`, `TicketWorkSource`.
|
||||
- Mock gateway normalise `tickets: []`.
|
||||
- Panneau Work affiche les tickets FIFO, source Human/Agent, preview, ticket court.
|
||||
- Refresh ajouté sur `delegationReady`.
|
||||
|
||||
- `5cb99fd` — `chore(wip): état runtime .ideai (flux conversation live, layouts)`
|
||||
- Runtime isolé des commits feature.
|
||||
|
||||
- `64c2c14` — merge local dans `develop`.
|
||||
|
||||
## QA verte
|
||||
|
||||
Commandes QA réelles validées:
|
||||
- `cargo fmt --all -- --check` OK.
|
||||
- `cargo test -p infrastructure mailbox --lib` OK, 13 passed.
|
||||
- `cargo test -p application --test workstate` OK, 12 passed.
|
||||
- `cargo test -p app-tauri --test dto_agents` OK, 20 passed.
|
||||
- `cargo check -p app-tauri` OK.
|
||||
- `cd frontend && npx vitest run src/features/workstate/workstate.test.tsx src/features/projects/projects.test.tsx` OK, 2 files / 17 tests.
|
||||
- `cd frontend && npx tsc --noEmit` OK.
|
||||
- QA ajoutée: `cargo test -p domain mailbox --lib` OK, 6 passed.
|
||||
|
||||
Warnings observés uniquement côté Vite sur options `esbuild` dépréciées/ignorées au profit de `oxc`, non bloquants.
|
||||
|
||||
## Décisions produit/techniques
|
||||
|
||||
- Les tickets `human` et `agent` sont inclus dans le snapshot; l'UI distingue explicitement `Human` vs agent/requester au lieu de tout appeler délégation agent.
|
||||
- Le statut est dérivé à la lecture: `inProgress` si le ticket courant correspond au `busy_state`, sinon `queued`.
|
||||
- Pas de nouvelle persistance, pas de lecture `log.jsonl`/handoff, pas d'événement `agentQueueChanged`, pas d'action UX d'annulation/résolution.
|
||||
|
||||
## Suite probable
|
||||
|
||||
Le prochain lot logique du chantier UX conversations/délégations est Lot C: résumés de conversations depuis log/handoff en lecture best-effort, ou Lot D actions UX selon priorité produit. Suivre le cycle Main: Architect -> Git -> DevBackend/DevFrontend -> QA -> Git.
|
||||
41
.ideai/memory/codex-network-access-config-fix.md
Normal file
41
.ideai/memory/codex-network-access-config-fix.md
Normal file
@ -0,0 +1,41 @@
|
||||
---
|
||||
name: codex-network-access-config-fix
|
||||
description: memory note codex-network-access-config-fix
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Correctif accès réseau Codex via `sandbox_workspace_write.network_access`
|
||||
|
||||
Le 2026-07-26, le diagnostic live a montré qu'un agent Codex lancé par IdeA échouait sur `curl` même avec IP forcée. La cause n'était pas seulement DNS ni une session à relancer : Codex CLI 0.145 attend la configuration officielle `sandbox_workspace_write.network_access=true` pour autoriser le réseau dans `workspace-write`.
|
||||
|
||||
Correctif implémenté et validé par QA dans les sources :
|
||||
|
||||
- Projection Codex `$CODEX_HOME/config.toml` : gérer `[sandbox_workspace_write] network_access = true/false` via `MergeToml`, pour éviter un stale `true`.
|
||||
- `codex exec` structuré : passer `-c sandbox_workspace_write.network_access=<bool>` quand la policy est connue.
|
||||
- La permission système IdeA reste séparée des permissions fichiers/bash : seul `NetworkPolicy::Allow` active `network_access=true`; `Deny`, `Ask` et `None` donnent `false`.
|
||||
- L'env `CODEX_SANDBOX_NETWORK_DISABLED` est encore upserté comme garde anti-héritage stale, mais ce n'est plus le mécanisme principal.
|
||||
|
||||
Fichiers principaux :
|
||||
|
||||
- `crates/infrastructure/src/permission/codex.rs`
|
||||
- `crates/domain/src/ports.rs`
|
||||
- `crates/application/src/agent/lifecycle.rs`
|
||||
- `crates/infrastructure/src/session/codex.rs`
|
||||
- `crates/application/src/ticket_assistant.rs`
|
||||
|
||||
Validation QA verte :
|
||||
|
||||
- `cargo test -p infrastructure permission::codex`
|
||||
- `cargo test -p infrastructure codex_`
|
||||
- `cargo test -p application --test agent_lifecycle codex_`
|
||||
- `cargo test -p application --test ticket_assistant codex_`
|
||||
- `cargo test -p domain`
|
||||
|
||||
Build réalisé :
|
||||
|
||||
- `npm --prefix frontend run build` : vert.
|
||||
- `tauri build --bundles appimage` : compilation release OK, mais bundling linuxdeploy a échoué car `appimagetool` tentait de télécharger le runtime sans réseau.
|
||||
- Contournement appliqué : `appimagetool --runtime-file /home/anthony/.cache/tauri/runtime-x86_64 ...`.
|
||||
- AppImage générée : `target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`, SHA-256 `08d74dfe950312f968f3fe5646d747f2ac6fa25f2a523a83825182f2809e2aa8`.
|
||||
|
||||
Validation live restante obligatoire : relancer IdeA depuis cette nouvelle AppImage, lancer un agent Codex frais avec `network: allow`, puis exécuter un vrai `curl`. La session Codex déjà active ne peut pas prouver le fix car elle a été lancée avant ces nouveaux arguments/config.
|
||||
59
.ideai/memory/context-agent-token-offload-design.md
Normal file
59
.ideai/memory/context-agent-token-offload-design.md
Normal file
@ -0,0 +1,59 @@
|
||||
---
|
||||
name: context-agent-token-offload-design
|
||||
description: memory note context-agent-token-offload-design
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Agent Context — allègement token, périmètre figé
|
||||
|
||||
Décision validée le 2026-07-23 : un nouvel agent **Context**, tournant sur un **LLM local peu
|
||||
puissant**, a été ajouté au projet IdeA pour réduire la fréquence des limites de tokens atteintes
|
||||
par les autres agents (Main, Architect, UX, DevBackend, DevFrontend, QA, Git) — **sans dégrader
|
||||
la qualité de leurs décisions**.
|
||||
|
||||
## Périmètre retenu (mécanique, faible risque)
|
||||
|
||||
- Recherche de symboles (localisation définition/usage).
|
||||
- Résumé de fichier(s) — factuel, pas d'interprétation architecturale.
|
||||
- Classification d'erreurs de compilation (tri d'un log brut).
|
||||
- Extraction des tests en échec (à partir d'une sortie de test brute).
|
||||
- Résumé de diff (`git diff` volumineux → liste factuelle de fichiers/nature de changement).
|
||||
- Repérage de fichiers probablement concernés par un ticket (piste, pas garantie).
|
||||
|
||||
## Explicitement exclu / dégradé en brouillon uniquement
|
||||
|
||||
Proposer un message de commit, générer un test unitaire, mettre à jour une documentation qui fait
|
||||
foi : ce sont des artefacts qui engagent une décision et qui appartiennent aux agents propriétaires
|
||||
(Git pour les commits, QA pour les tests). Un modèle local faible qui les produit comme livrable
|
||||
ferait courir un risque de qualité que la vérification par l'agent fort annulerait de toute façon
|
||||
le gain de tokens visé. Context peut produire un brouillon explicitement marqué comme tel, jamais
|
||||
un livrable.
|
||||
|
||||
## Garde-fous de fiabilité (vu la faiblesse du modèle)
|
||||
|
||||
Context ne décide rien, ne corrige pas de code de production, ne remplace jamais une vérification
|
||||
qui doit être prouvée (tests QA, verdict de build), et ne devine jamais quand l'information manque
|
||||
— il doit dire "non trouvé"/"incertain" plutôt qu'extrapoler. Réponses courtes, structurées,
|
||||
citant ce qui a été effectivement vu (chemins, lignes), sans jugement de valeur.
|
||||
|
||||
## Où c'est câblé
|
||||
|
||||
- Contexte agent : `.ideai/agents/context.md` (écrit via `idea_update_context`).
|
||||
- Template global IdeA créé : « Context — Agent d'assistance légère à faible coût »
|
||||
(`defaultProfileId` = profil LLM local de l'agent Context), pour réutilisation cross-projet.
|
||||
Le template ne contient que la partie générique (aucune référence à IdeA le produit) ;
|
||||
la déclaration des 7 autres rôles nommés reste project-spécifique et vit dans
|
||||
`.ideai/agents/context.md` du projet, pas dans le template.
|
||||
- Rôle ajouté à la liste des rôles du contexte projet global (CLAUDE.md §3) : Context ne fait
|
||||
**pas** partie du cycle obligatoire (§4) — pas d'étape qui lui est dédiée, il est sollicité en
|
||||
support ponctuel par n'importe quel agent.
|
||||
- Chaque agent (Main, Architect, DevBackend, DevFrontend, QA, Git, UX) a reçu un ajout court dans
|
||||
sa section « Délégation & collaboration » expliquant quand solliciter Context et rappelant que
|
||||
son résultat est une piste à vérifier, jamais une conclusion ou une décision.
|
||||
|
||||
## Pourquoi
|
||||
|
||||
Voir [[idea-product-directives-main-handoff]] pour les directives produit générales ; cette note
|
||||
couvre spécifiquement le compromis coût-tokens/qualité qui a motivé le périmètre volontairement
|
||||
restreint de Context (pas de délégation de jugement, seulement de compression/extraction
|
||||
factuelle).
|
||||
@ -1,16 +0,0 @@
|
||||
---
|
||||
name: f35-launch-status-done-config-crud-blocked
|
||||
description: F35.1 UI statut de lancement du serveur local livrée+verte ; F35.2 config CRUD bloquée sur un DTO figé qui ne matche pas le wire réel + delete manquant.
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
Ticket #35 sur `feature/modeles-locaux`.
|
||||
|
||||
**F35.1 LIVRÉ (vert)** : événements `model_server_status_changed`/`agent_launch_failed` déjà exposés via `domain://event`. Consommés dans `useAgents` → `modelServerStatusByServer` (par serverId) + `launchFailureByAgent` (par agentId). Badge `ModelServerLaunchBadge` monté par ligne dans `AgentsPanel`, corrélé via `profile.opencode.localModelServerId`. Contrat réel ≠ DTO figé du ticket : `serverId` sur l'enveloppe (pas par état) ; états camelCase `notConfigured|probing|starting|ready{reused}|failed{code,message}` ; PAS de `baseURL`/`model` émis dans le statut. Je me suis aligné sur le wire réel.
|
||||
|
||||
**F35.2 BLOQUÉ — 3 gaps backend remontés à Main :**
|
||||
1. (bloquant) `save_model_server`/`list_model_servers` transmettent le domaine `LocalModelServerConfig` en `serde(transparent)`, forme IMBRIQUÉE : `{id, kind:"llamaCpp", name, endpoint:{baseURL,port}, model:{id,label,path?,servedName}, binary?, args, autoStart, stopPolicy}`. Le DTO figé du ticket est plat et FAUX (kind "llamacpp", baseURL/port/modelPath/servedModelName/binaryPath à plat). Pire : `model` exige `id`+`label` non-vides (LocalModelRef::new) absents du DTO figé → payload figé rejeté. Besoin arbitrage Architect : (A) couche DTO plate app-tauri qui remplit model.id/label, ou (B) MAJ du DTO figé vers la forme imbriquée + sémantique de model.id/label.
|
||||
2. Pas de commande `delete_model_server`.
|
||||
3. (côté moi) créer `ModelServerGateway`/port/adapter une fois le contrat tranché.
|
||||
|
||||
Saisie simple de `localModelServerId` (F36) laissée en place, pas de régression. tsc propre ; suite 593/593.
|
||||
14
.ideai/memory/frontend-uses-npm-not-pnpm.md
Normal file
14
.ideai/memory/frontend-uses-npm-not-pnpm.md
Normal file
@ -0,0 +1,14 @@
|
||||
---
|
||||
name: frontend-uses-npm-not-pnpm
|
||||
description: memory note frontend-uses-npm-not-pnpm
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
Le dossier `frontend/` s'installe et se build avec **npm**, jamais pnpm (lockfile `package-lock.json`).
|
||||
|
||||
**Ne jamais lancer `pnpm` (ni `corepack pnpm build`, ni le wrapper `pnpm --dir frontend build`) dans `frontend/`** :
|
||||
- `pnpm --dir frontend build` échoue d'abord sur un pré-check `pnpm install` (`ERR_PNPM_IGNORED_BUILDS` sur esbuild).
|
||||
- Surtout, `pnpm install` **clobber** le `node_modules` npm : pnpm aplatit `vite@5.4.21` au top-level alors que `vitest@4.1.x` exige `vite ^6||^7||^8`. Résultat : `ERR_PACKAGE_PATH_NOT_EXPORTED: './module-runner'` dès que vitest spawn son worker pool (>3 fichiers de test). Avec npm, `vite@8` est imbriqué sous `node_modules/vitest/node_modules/vite`, donc tout marche.
|
||||
- Réparation si le clobber arrive : `rm -f frontend/pnpm-lock.yaml frontend/pnpm-workspace.yaml && cd frontend && npm install`, puis `git checkout -- frontend/package-lock.json`.
|
||||
|
||||
Commandes correctes sans le wrapper cassé : `cd frontend && npx tsc --noEmit && npx vite build` (build) et `npx vitest run` (tests). Le script `pnpm build` du package.json ne doit pas être utilisé tel quel dans cet environnement.
|
||||
@ -0,0 +1,19 @@
|
||||
---
|
||||
name: idea-distribution-strategy-desktop-vs-docker
|
||||
description: memory note idea-distribution-strategy-desktop-vs-docker
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
Stratégie de distribution IdeA validée utilisateur (2026-07-16, suite #13) : DEUX offres au-dessus du MÊME cœur backend (pas de fork métier).
|
||||
|
||||
**Offre 1 — Full desktop** : binaire Tauri `app-tauri` actuel. AppImage Linux (existe, inchangée). Windows explicitement REPORTÉ (garder la portabilité à l'esprit, ne rien introduire de non-portable ; PTY = ConPTY à retester le jour venu). L'AppImage reste desktop PUR — elle ne bundle pas les assets web.
|
||||
|
||||
**Offre 2 — Serveur/client** : image Docker, bâtie sur un binaire serveur HEADLESS `idea-serve` SANS dépendance Tauri/WebKit (pas de dockerisation du binaire Tauri qui traînerait GTK/WebKit pour rien). Cadré faisable en hexagonal par Architect.
|
||||
|
||||
**Point pivot technique** : `server.rs` vit dans `crates/app-tauri` et réutilise indirectement la présentation Tauri via `crate::state::AppState`, `crate::dto::*`, `crate::events::DomainEventDto`, `crate::pty::PtyChunk`, `crate::mcp_endpoint::*`, `ResumeContext`. Le protocole HTTP/WS lui est déjà autonome. Le vrai travail = découpler les DTO (→ crate partagé `presentation-dto`/`backend-api`) puis extraire `crates/web-server` (sur `BackendCore`, pas `AppState`) puis le bin `idea-serve`.
|
||||
|
||||
**Tickets** : #65 (headless, high, L1 DTO→L2 web-server→L3 idea-serve), #66 (Docker, medium, L4 build web http→L5 Dockerfile volumes /data+/workspace→L6 agents CLI conteneur), #64 (folder browser web, dependsOn #66 pour /workspace), #67 (lock inter-process app-data-dir, low).
|
||||
|
||||
**Topologie de branches (décision utilisateur)** : chantier packaging sur `feature/server-client-packaging` (créée depuis `c246875`, tête de `feature/ticket13-pty-websocket`). PAS de merge dans develop tant que l'utilisateur n'a pas validé lui-même la NON-RÉGRESSION desktop-only. Flux final : `feature/server-client-packaging` → `feature/ticket13-pty-websocket` → `develop`. Git rebase la branche packaging si #13 avance.
|
||||
|
||||
Invariants : desktop AppImage ne perd RIEN ; aucun import Tauri dans le bin headless ; même cœur/use cases/stores ; contrat HTTP/WS inchangé sauf lot versionné. Voir [[frontend-uses-npm-not-pnpm]], [[appimage-build-no-strip-relr-dyn-fix]].
|
||||
@ -1,47 +0,0 @@
|
||||
---
|
||||
name: mcp-e2e-findings-reply-wedge-phantom-busy
|
||||
description: memory note mcp-e2e-findings-reply-wedge-phantom-busy
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
name: mcp-e2e-findings-reply-wedge-phantom-busy
|
||||
description: Findings validation MCP e2e live (AppImage 0.3.0) — transport/rendez-vous SAINS ; un seul vrai défaut = wedge si l'agent délégué n'appelle pas idea_reply (pas de timeout serveur).
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Findings validation MCP e2e (live, AppImage 0.3.0) — 2026-06-22
|
||||
|
||||
Contexte : validation réelle du parcours inter-agents (cf. [[resume-after-appimage-rebuild-mcp-e2e]]). Méthode = Main observe en externe (Bash sur `ss -xp` + transcripts `~/.claude/projects/<run-dir-encodé>/*.jsonl`), l'utilisateur déclenche dans l'UI ; on ne valide PAS via `idea_ask_agent`.
|
||||
|
||||
## Scénario 1 — délégation vers agent FROID + cycle complet : VERDICT
|
||||
- ✅ **Réveil à froid** : déléguer vers un agent arrêté relance son pont (`mcp-server --requester <id>` réapparaît, socket ESTAB recompte).
|
||||
- ✅ **1er tour non perdu** : tâche livrée intacte = 1er `user` `[IdeA · tâche de <agent> · ticket <uuid>] …`.
|
||||
- ✅ **Chemin positif `idea_reply`** : quand l'agent cible appelle `idea_reply(ticket,result)`, le bridge répond `reply ... delivered`, le **demandeur reçoit le `tool_result` et reprend la main** (vérifié : DevBackend reçoit `pong` puis continue).
|
||||
- ✅ **Purge live-state** : dès l'`idea_reply`, `idea_workstate` repasse le cible de `working` → `done`, intent vidé.
|
||||
|
||||
➡️ **Transport + protocole de rendez-vous = SAINS.** Bugs historiques 3/4/5 OK sur ce chemin.
|
||||
|
||||
## LE défaut restant (racine unique) — wedge sans `idea_reply`
|
||||
Si l'agent délégué **termine son tour sans appeler `idea_reply`** (ex. tâche triviale « réponds pong » → il répond `pong` en **prose** et s'arrête) :
|
||||
- le **demandeur wedge indéfiniment** dans `idea_ask_agent` (transcript demandeur figé sur le `tool_use` idea_ask_agent, aucun `tool_result`) ;
|
||||
- la **cible reste `working`** sur le ticket périmé dans la live-state ;
|
||||
- **aucun timeout ni récupération** côté serveur. Une interruption utilisateur du `ask` libère le demandeur mais **ne purge pas** le `working` de la cible (purge seulement à l'`idea_reply`).
|
||||
|
||||
➡️ Le « Busy fantôme » n'est PAS un bug d'état indépendant : c'est la **conséquence** de l'absence d'`idea_reply`. Une seule cause à traiter.
|
||||
|
||||
### Pistes correctif (à arbitrer Architect)
|
||||
1. **Durcir contextes agents** : « toute tâche déléguée se termine IMPÉRATIVEMENT par `idea_reply`, même triviale » (cheap, attaque la cause comportementale).
|
||||
2. **Garde-fou serveur (rendez-vous)** : timeout sur l'attente `idea_ask_agent` → renvoyer au demandeur un résultat d'échec/relance explicite + purger le `working` de la cible (idempotent). Touche le contrat rendez-vous + cycle de vie live-state = domaine Architect. Voir [[idea-program-surface-separation-and-livestate]], [[mcp-bridge-and-delegation-runtime-notes]].
|
||||
|
||||
## Diagnostic / repro (rappels)
|
||||
- Ponts : `pgrep -af 'mcp-server --endpoint'` (1 requester = 2 process) ; `ss -xp | grep -c idea-mcp`.
|
||||
- Reply réel = `tool_use` `idea_reply` dans le transcript cible → tool_result `reply ... delivered` (⚠️ ne pas confondre avec les mentions `idea_reply` du CLAUDE.md injecté via attachments).
|
||||
- Wedge demandeur = transcript demandeur s'arrête sur `tool_use` `idea_ask_agent` sans `tool_result`.
|
||||
- ⚠️ Horodatages transcripts = **UTC** ; `ls %H:%M:%S` masque la date → comparer avec `date` + mtime réel (`ls -t`).
|
||||
|
||||
## Restant à tester (scénarios e2e suivants)
|
||||
- Délégation vers agent BACKGROUND (node_id None) — même protocole, vérifier pas de 1er tour perdu.
|
||||
- `ask` sans réponse ne wedge pas durablement la CONNEXION du demandeur (vs juste l'appel) — Bug 5 côté transport.
|
||||
- Profils Claude/Codex utilisent MCP par défaut ; fallback fichier+prose cohérent.
|
||||
- Observabilité UI des délégations/replies (aujourd'hui opaque) — sujet UX.
|
||||
@ -1,45 +0,0 @@
|
||||
---
|
||||
name: mcp-functional-test-plan-2026-06-24
|
||||
description: memory note mcp-functional-test-plan-2026-06-24
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
name: mcp-functional-test-plan-2026-06-24
|
||||
description: Plan de test FONCTIONNEL du rendez-vous inter-agents MCP (trivial→tordu), à exécuter après rebuild develop HEAD ; méthode, ordre, setup IdeA et critères de réussite.
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Plan de test fonctionnel MCP inter-agents (2026-06-24, run a6ced819)
|
||||
|
||||
Objectif : état des lieux par tests **fonctionnels** (pas unitaires) du rendez-vous `idea_ask_agent` ⇄ `idea_reply`, du trivial au plus tordu. On lance dans l'ordre, on **s'arrête au 1er blocage**, on corrige (cycle Architect→Git→Dev→QA), rebuild+relance, puis on **reprend de T1**. Contexte/historique : [[mcp-e2e-findings-reply-wedge-phantom-busy]], [[backstop-fires-on-intra-task-turn-rootcause]], [[rendezvous-no-reply-backstop-design]], [[rendezvous-600s-cap-too-short-heavy-tasks]], [[reconcile-live-state-implemented-feature-branch]].
|
||||
|
||||
## Contexte binaire au moment du plan
|
||||
- AppImage qui tournait = build **23/06 19:42**, PÉRIMÉ (antérieur à `c6f0f86` encode_cwd, `744de20` backstop no-reply, `886bb0d`/`1efe2f1` reconcile). Décision utilisateur : **rebuild develop HEAD `1efe2f1` puis relance** avant de tester.
|
||||
- Règle structurelle : **binaire qui tourne = AppImage**. Tout fix backend ⇒ rebuild + relance d'IdeA (tue Main). Les tests s'enchaînent SANS relance *à l'intérieur d'une même version* ; chaque cycle de fix = 1 relance.
|
||||
|
||||
## Méthode
|
||||
- **Main est le demandeur** (`idea_ask_agent`) = test fidèle de « si je donne un message à un agent, il me répond ».
|
||||
- Doublé d'**observation externe Bash** : ponts `ss -xp | grep idea-mcp` et `pgrep -af mcp-server` ; transcripts `~/.claude/projects/<run-dir-encodé>/*.jsonl` (horodatages **UTC** ; reply réel = `tool_use` idea_reply→tool_result `reply … delivered` ; wedge demandeur = transcript figé sur `tool_use` idea_ask_agent sans tool_result) ; live-state via `idea_workstate_read`.
|
||||
- Risque résiduel : un wedge non borné fige le tour de Main → l'utilisateur peut interrompre.
|
||||
|
||||
## Setup IdeA à mettre en place avant T1 (consigne utilisateur)
|
||||
1. Relancer IdeA, ouvrir le projet IdeA, **Main visible** (le demandeur).
|
||||
2. Garder **2–3 cellules libres visibles** pour qu'on observe à l'œil les délégations (Main y placera des cibles visibles, ou lance-toi QA + DevFrontend dans des cellules visibles).
|
||||
3. **Laisser Architect, DevBackend, Git ARRÊTÉS (froids)** : T3 testera le réveil à froid ; T9 utilisera Architect+DevBackend froids.
|
||||
4. Cibles chaudes pour T1/T2 : Main les réchauffe lui-même (launch) — pas d'action requise.
|
||||
|
||||
## Ordre des tests (trivial → tordu)
|
||||
- **T1 — Visibilité outils MCP.** Un agent lancé par IdeA voit ses outils sans action manuelle. Vérif : pont ESTAB (`ss`) + 2 process mcp-server par requester.
|
||||
- **T2 — Cible CHAUDE + idea_reply trivial.** Main→ask(agent chaud, « réponds pong via idea_reply »). Attendu : réponse inline `pong`, temps borné, workstate working→done purgé.
|
||||
- **T3 — Réveil à FROID + idea_reply.** Cible arrêtée. Attendu : pont relancé (nouveau mcp-server), **1er tour non perdu** (1er user `[IdeA · tâche…]` intact), reply remonte.
|
||||
- **T4 — Cible BACKGROUND (node_id None).** Délégation vers agent sans cellule visible. Attendu : même protocole, pas de 1er tour perdu (historiquement non testé).
|
||||
- **T5 — NO-REPLY (cible répond en prose, pas d'idea_reply).** Attendu backstop : demandeur libéré en temps borné avec `TargetReturnedNoReply` (retryable), **pas de Busy fantôme** (workstate purgé). DÉFAUT historique #1.
|
||||
- **T6 — Délégation MULTI-ÉTAPES puis idea_reply.** Cible lit plusieurs fichiers / lance une cmd PUIS idea_reply. Attendu : **pas de libération prématurée** pendant le travail, rapport final livré. PIÈGE turn-watcher (cause racine : backstop tirait au 1er tour interne ~3 s).
|
||||
- **T7 — Tâche LOURDE > plafond** (impl + `cargo test`/clippy). Attendu : extension sur signe de vie OU message clair « cible active, plafond atteint » (≠ faux `-32001`) ; idea_reply tardif non perdu. Plafond `IDEA_ASK_RENDEZVOUS_TIMEOUT_MS` (défaut 600000).
|
||||
- **T8 — Délégations PARALLÈLES** (2 cibles en 1 tour Main). Attendu : rendez-vous multiples simultanés OK, multiplexage pont, 2 réponses distinctes.
|
||||
- **T9 — TRANSITIVE A→B→C** (Main→Architect, Architect délègue à DevBackend puis reply à Main). Attendu : rendez-vous imbriqués, 2 attentes simultanées sans deadlock. Cas le plus tordu.
|
||||
- **T10 — INTERRUPTION/annulation + reconcile reboot.** (a) Main interrompt un ask en vol → `working` cible purgé, pas de cascade, idea_reply tardif non-livrable proprement. (b) Au reboot, orphelins status∈{working,waiting,blocked} & session morte → `idle` + marker `STALE_AT_RESTART_MARKER` (use case ReconcileLiveState, cf. [[reconcile-live-state-implemented-feature-branch]]).
|
||||
|
||||
## Critère de fin
|
||||
Tous les T1→T10 verts avec preuve réelle (réponse inline + observation externe cohérente). Sinon : 1er rouge = blocage à corriger, puis reprise de T1.
|
||||
@ -1,33 +0,0 @@
|
||||
---
|
||||
name: mcp-functional-tests-t1-t9-green-live-2026-06-24
|
||||
description: memory note mcp-functional-tests-t1-t9-green-live-2026-06-24
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
title: MCP tests fonctionnels T1→T9 VERTS en live (2026-06-24, AppImage 12:53 HEAD 1efe2f1 + fix T7 non committé)
|
||||
type: project
|
||||
description: Passe complète T1→T9 verte en conditions réelles sur AppImage du 24/06 12:53 ; T5 (backstop no-reply) et T7 (watchdog inactivité >600s) validés live ; reste T10 (interruption + reconcile reboot) qui exige action utilisateur.
|
||||
---
|
||||
# Tests fonctionnels MCP rendez-vous — T1→T9 VERTS live (2026-06-24)
|
||||
|
||||
Run a6ced819, plan [[mcp-functional-test-plan-2026-06-24]]. AppImage **rebuild 12:53 depuis l'arbre de travail** (HEAD `1efe2f1` + le fix T7 watchdog **non committé** mais présent dans les 11 fichiers modifiés du git status → embarqué dans le binaire). Méthode : Main demandeur + observation externe (ss/pgrep/transcripts UTC/workstate).
|
||||
|
||||
## Résultats (preuve réelle)
|
||||
- **T1 visibilité MCP** ✅ : agents chauds = pont ESTAB + 2 mcp-server (app-tauri parent + AppImage) chacun.
|
||||
- **T2 cible chaude + reply trivial** ✅ : DevFrontend → `pong` inline, reply delivered 10:56:51 UTC, workstate done (pas de Busy fantôme).
|
||||
- **T3 réveil à FROID** ✅ : Git froid → `pong-cold` ; nouveau pont spawné, **1er tour `[IdeA·tâche]` intact** (régresseur encode_cwd résolu), reply delivered 10:57:34.
|
||||
- **T4 cible BACKGROUND (node_id None)** ✅ : Git background → `pong-bg`, reply delivered 10:58:14.
|
||||
- **T5 NO-REPLY backstop** ✅ (défaut historique #1 résolu) : cible répond en prose sans idea_reply → demandeur libéré en ~20 s avec erreur retryable « returned to its prompt without calling idea_reply », workstate cible done (PAS de Busy fantôme).
|
||||
- **T6 multi-étapes** ✅ (piège turn-watcher résolu) : DevFrontend lit fichiers + git log PUIS idea_reply ; pas de libération prématurée ; données réelles (142 fichiers, hashes corrects).
|
||||
- **T7 tâche LOURDE >600s** ✅ (défaut historique #2 résolu, validation live du fix watchdog) : QA charge réelle continue 11:00:46→11:12:44 UTC = **~11m58s**, cargo clean+build release+test (1632 passed/0)+clippy+9 relances ; rendez-vous **NON expiré à 600s**, idea_reply accepté au-delà du plafond (aucun « no pending request »), reply delivered 11:13:21.
|
||||
- **T8 PARALLÈLE** ✅ : 2 asks même tour (DevFrontend `alpha-8` + Git `beta-8`), réponses distinctes, multiplexage pont OK.
|
||||
- **T9 TRANSITIF A→B→C** ✅ : Main→Architect→DevBackend (les 2 froids) → `relay:gamma-9:done` ; rendez-vous imbriqués + double réveil à froid sans deadlock ; DevBackend reply delivered 11:14:32.
|
||||
|
||||
## Reste : T10 (exige action utilisateur)
|
||||
- **T10a interruption** : Main interrompt un ask en vol → attendu : workstate cible purgé, pas de cascade, idea_reply tardif proprement non-livrable. NÉCESSITE que l'utilisateur appuie sur interrupt pendant un ask wedgé.
|
||||
- **T10b reconcile reboot** : orphelin status∈{working,waiting,blocked} + session morte → au reboot, use case ReconcileLiveState le passe à idle + `STALE_AT_RESTART_MARKER` (cf. [[reconcile-live-state-implemented-feature-branch]]). NÉCESSITE un reboot d'IdeA (ferme Main).
|
||||
|
||||
## Suite recommandée
|
||||
1. Faire committer le fix T7 par Git (encore non committé, cf. [[git-owns-commit-merge-decisions]] + [[rendezvous-600s-cap-too-short-heavy-tasks]]).
|
||||
2. Exécuter T10 avec l'utilisateur (interrupt + reboot).
|
||||
@ -1,29 +0,0 @@
|
||||
---
|
||||
name: mcp-t10a-harness-interrupt-does-not-cancel-rendezvous
|
||||
description: memory note mcp-t10a-harness-interrupt-does-not-cancel-rendezvous
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
title: T10a — l'interrupt harness du demandeur n'annule PAS le rendez-vous backend (reply tardif accepté dans le vide)
|
||||
type: reference
|
||||
description: Finding T10a (2026-06-24) — interrompre Main (demandeur) au niveau Claude Code ne propage aucune annulation à IdeA ; la cible finit, son idea_reply est « delivered » dans un demandeur abandonné, et la live-state du demandeur reste working.
|
||||
---
|
||||
# Finding T10a (2026-06-24, run a6ced819)
|
||||
|
||||
## Setup
|
||||
Main → `idea_ask_agent(DevFrontend, "travaille ~90s puis idea_reply late-10a")`. Pendant l'attente, l'utilisateur **interrompt Main** (Échap harness Claude Code). Le tool use `idea_ask_agent` est rejeté côté harness.
|
||||
|
||||
## Observé
|
||||
- DevFrontend a fini ses ~95 s de travail réel (11:20:39→11:22:14 UTC) puis `idea_reply("late-10a")` → **ACCEPTÉ « delivered »** à 11:22:18 (PAS « no pending request »).
|
||||
- DevFrontend workstate = **done** (pas d'orphelin côté cible). Pas de cascade.
|
||||
- **Main (demandeur) workstate resté `working`** : l'interrupt a coupé le tour de Main avant son nettoyage ; le chemin interrupt ne réconcilie pas la live-state du demandeur.
|
||||
|
||||
## Interprétation
|
||||
L'interrupt Claude Code annule le **tool call local** mais le **process Main survit** → la socket MCP (mcp-server du demandeur) reste connectée → IdeA ne reçoit aucun signal d'annulation → le rendez-vous reste pending → le reply tardif de la cible est livré dans un demandeur qui a déjà abandonné (perdu pour Main mais rapporté « delivered »).
|
||||
|
||||
## Conséquence
|
||||
- Le T10a du plan (« annulation en vol → reply tardif non-livrable proprement ») **n'est pas exerçable via interrupt harness** tant que le process demandeur survit. Une vraie annulation exigerait : tuer le process demandeur (drop socket) OU un cancel protocolaire JSON-RPC.
|
||||
- Comportement néanmoins bénin : pas de wedge, pas de cascade, cible réconciliée (done). Seuls écarts : (a) reply tardif « delivered » au lieu de rejeté ; (b) live-state du demandeur laissée working par le chemin interrupt (mais reconcile-au-reboot la rattraperait, cf. [[reconcile-live-state-implemented-feature-branch]]).
|
||||
|
||||
Lié à [[mcp-functional-tests-t1-t9-green-live-2026-06-24]], [[mcp-functional-test-plan-2026-06-24]].
|
||||
@ -1,24 +0,0 @@
|
||||
---
|
||||
name: mcp-t10b-pending-reboot-verification
|
||||
description: memory note mcp-t10b-pending-reboot-verification
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
title: T10b PASS — reconcile au reboot vérifié, inclut l'orchestrateur (2026-06-24)
|
||||
type: project
|
||||
description: T10b validé live après reboot. ReconcileLiveState ramène l'orphelin Main working→idle en conservant l'intent et purgeant ticket/lastDelegation. Couvre l'orchestrateur. Reste : faire committer par Git les fix non committés (T7 watchdog + reconcile).
|
||||
---
|
||||
# T10b — PASS (reboot reconcile vérifié)
|
||||
|
||||
## Verdict
|
||||
Orphelin armé = Main `working` intent "T10b-ORPHAN-MAIN". Après reboot (run a6ced819), `idea_workstate_read` montre Main :
|
||||
- `status: idle` ✅ (était working)
|
||||
- `intent` conservé ✅
|
||||
- `ticket` purgé ✅ / `lastDelegation` purgé ✅
|
||||
|
||||
Signature `STALE_AT_RESTART_MARKER` complète. **ReconcileLiveState valide ET inclut l'orchestrateur** (Main n'a PAS été exclu malgré la crainte du design open_project). Champ `progress` non exposé par workstate_read mais transition working→idle+intent retenu = concluante.
|
||||
|
||||
## Suite du plan
|
||||
T1→T10 du plan [[mcp-functional-test-plan-2026-06-24]] terminés (T1→T9 verts cf. [[mcp-functional-tests-t1-t9-green-live-2026-06-24]], T10a finding [[mcp-t10a-harness-interrupt-does-not-cancel-rendezvous]], T10b PASS ici).
|
||||
**RESTE : faire committer par Git les fix non committés (T7 backstop/watchdog + reconcile live-state).** cf. [[git-owns-commit-merge-decisions]].
|
||||
@ -1,37 +0,0 @@
|
||||
---
|
||||
name: mcp-t7-backstop-600s-reply-rejected-livestate-stale
|
||||
description: memory note mcp-t7-backstop-600s-reply-rejected-livestate-stale
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
title: MCP T7b/T7e — backstop 600s rejette le reply tardif et laisse le live-state worker non réconcilié
|
||||
type: reference
|
||||
description: Finding fonctionnel des tests MCP T7b/T7e (2026-06-24) — un idea_reply après dépassement de la fenêtre 600s est refusé « no pending request », et le ticket du worker reste working dans le live-state.
|
||||
---
|
||||
|
||||
# Finding — tests MCP T7 (2026-06-24, QA)
|
||||
|
||||
## Contexte
|
||||
Série de tests du rendez-vous `idea_ask_agent ⇄ idea_reply` et du backstop no-reply (cap ~600s), demandés par Main :
|
||||
- **T7d** (debug build x3, avant-plan) : cumul ~3m49s < 600s → reply OK.
|
||||
- **T7b** (9 étapes `sleep 82`, entrelacées) : le harness BLOQUE tout `sleep` avant-plan → exécutées en run_in_background ; reply OK (tardif mais < fenêtre côté ticket T7b).
|
||||
- **T7e** (release build répété, avant-plan, sans sleep ni bg) : 7 cycles, cumul réel **08:01:14 → 08:14:21 = 13 min 07 s**, franchit largement 600s.
|
||||
|
||||
## Défaut observé
|
||||
À la fin de T7e (et de T7b, terminé au même tour, après >600s d'occupation continue), les DEUX `idea_reply` (tickets `4613262f…` T7b et `d2398b22…` T7e) sont refusés :
|
||||
|
||||
```
|
||||
invalid input: no pending request to reply to for agent aefdbd61-…
|
||||
```
|
||||
|
||||
→ Le backstop a libéré le **demandeur** (Main) côté rendez-vous après dépassement du cap, ce qui est le comportement voulu. MAIS :
|
||||
1. Le **résultat réel** (builds OK, horodatages non falsifiés) ne peut **plus être délivré** : il est perdu pour le demandeur.
|
||||
2. `idea_workstate_read` montre encore le worker QA `status=working ticket=d2398b22…` **après** le rejet du reply → le live-state du **worker** n'est PAS réconcilié quand le backstop ferme le rendez-vous côté demandeur. Incohérence demandeur (libéré) vs worker (toujours working).
|
||||
|
||||
## Conséquence / piste
|
||||
- Le cap 600s du rendez-vous reste trop court pour des tâches lourdes légitimes (cf. [[rendezvous-600s-cap-too-short-heavy-tasks]]) : ici un travail réel et honnête >13 min est « jeté ».
|
||||
- À corriger : quand le backstop ferme un rendez-vous, soit (a) accepter encore un reply tardif (le router vers le demandeur même après timeout / le persister), soit (b) réconcilier le live-state du worker (passer son ticket à done/abandon) pour ne pas laisser un `working` fantôme. Voir [[backstop-fires-on-intra-task-turn-rootcause]] et [[rendezvous-no-reply-backstop-design]].
|
||||
|
||||
## Reproductible
|
||||
Charge avant-plan réelle (`cargo build --release --workspace` en boucle clean) dépassant 600s, puis tenter `idea_reply` sur le ticket d'origine → rejet systématique.
|
||||
25
.ideai/memory/model-catalogue-compat-cadrage.md
Normal file
25
.ideai/memory/model-catalogue-compat-cadrage.md
Normal file
@ -0,0 +1,25 @@
|
||||
---
|
||||
name: model-catalogue-compat-cadrage
|
||||
description: Frontières hexagonales, ports, DTO, fallback et matrice de compatibilité versionnée pour l'évolution du catalogue de modèles des profils structurés Codex/Claude.
|
||||
metadata:
|
||||
type: reference
|
||||
---
|
||||
Évolution de `ListClaudeModels`/`ListCodexModels` (catalogue statique `application/src/agent/model_catalogue.rs`) vers un catalogue enrichi par compatibilité CLI.
|
||||
|
||||
**Décisions tranchées :**
|
||||
- JAMAIS scraper les TUI `/model`, JAMAIS exécuter les CLIs pour énumérer les modèles. Seule exécution CLI autorisée : `<cli> --version` (pattern existant `infrastructure/runtime::detection_spec` + port `ProcessSpawner`). Saisie libre toujours ouverte.
|
||||
- 3 sources non bloquantes à dégradation indépendante : API provider `/v1/models` (best-effort, uniquement si clé env/SecretStore présente, sinon skip), catalogue statique seed, matrice de compat.
|
||||
|
||||
**Hexagonal :**
|
||||
- Domaine (pur) : VO `CliVersion` (Ord), enum `ModelCompatibility {Compatible|Unknown|LikelyTooRecent}` (miroir des 3 états produit), VO `CompatibilityMatrix` (forme seule), fonction pure `evaluate_compatibility(matrix, adapter, model_id, Option<CliVersion>)` — version None ⇒ Unknown, modèle absent ⇒ Unknown, min<=ver ⇒ Compatible, min>ver ⇒ LikelyTooRecent.
|
||||
- Nouveaux ports : `CliVersionReader`, `ProviderModelCatalogue` (Ok(vec![]) si pas de clé), `CompatibilityMatrixSource` (infaillible).
|
||||
- Application : use case unique `ResolveModelCatalogue{adapter}` async, jamais de hard-error sur échec source (warnings + fallback). `ListClaude/CodexModels` deviennent des façades.
|
||||
- Infra : `ProcessCliVersionReader`, `HttpProviderModelCatalogue` (reqwest), `EmbeddedCompatibilityMatrix`.
|
||||
|
||||
**Matrice de compat = DONNÉE, pas code** : JSON versionné maintenu dans IdeA, bundlé via `include_str!` (seed infaillible) + override optionnel `app_data_dir/IdeA/model-compat.json`. Ajouter un modèle = éditer le JSON, zéro code (Open/Closed).
|
||||
|
||||
**DTO (rupture front)** : `ProfileModelCatalogDto` passe de `transparent Vec` à `{ models:[{...,compatibility,source}], cliVersion:string|null, warnings:string[] }`. Répercuter ports TS + 2 adapters + mock + ProfilesSettings.
|
||||
|
||||
**Découpage** : B1 domaine pur, B2 use case ports mockés, B3 infra ; F1 contrat, F2 ProfilesSettings 3 badges. UX passe avant F2 (libellés des 3 états, warnings, cliVersion null).
|
||||
|
||||
**Point ouvert produit** : récup clé provider — proposé best-effort sur clé env/SecretStore existante, pas de prompt dédié.
|
||||
@ -0,0 +1,50 @@
|
||||
---
|
||||
name: multi-profile-codex-claude-model-catalogue-scoping
|
||||
description: memory note multi-profile-codex-claude-model-catalogue-scoping
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Cadrage : profils multiples Codex/Claude + catalogue de modèles
|
||||
|
||||
Demande utilisateur : plusieurs profils Codex et Claude, chacun avec son modèle, assignables aux
|
||||
agents ; lister les modèles plutôt que saisie manuelle quand possible.
|
||||
|
||||
## État vérifié de l'existant (2026-07-26)
|
||||
|
||||
Le backend est déjà générique multi-profils, contrairement à ce qu'on pourrait croire à la lecture
|
||||
seule des mémoires F35/F36 (qui documentaient le cas OpenCode) :
|
||||
|
||||
- `AgentProfile` (crates/domain/src/profile.rs) porte déjà `model: Option<String>` (ticket #99,
|
||||
explicitement prévu pour Codex/Claude), et `profiles.json` (FsProfileStore) est une **liste**
|
||||
indexée par `id`, pas un slot singleton par provider.
|
||||
- Commandes déjà câblées : `list_profiles`, `save_profile` (upsert générique par id),
|
||||
`delete_profile`, `reference_profiles`, `detect_profiles`.
|
||||
- Ce qui existe **seulement pour OpenCode** : `clone_opencode_profile_from_seed` (alloue un id
|
||||
frais via IdGenerator) et `save_opencode_provider_profile`, plus un vrai catalogue de modèles
|
||||
(`crates/application/src/agent/provider_catalogue.rs`, lit le cache models.dev d'OpenCode avec
|
||||
repli statique).
|
||||
- `catalogue.rs` : un seul profil de référence Claude et un seul Codex, aucun `.with_model(...)`.
|
||||
- Frontend `ProfilesSettings.tsx` : simple list+delete, pas de create/duplicate/edit inline ;
|
||||
toute édition rouvre `FirstRunWizard`.
|
||||
|
||||
## Gaps identifiés (pas de migration de schéma nécessaire)
|
||||
|
||||
1. Backend : généraliser le pattern `CloneOpenCodeProfileFromSeed` (fresh_profile_id via
|
||||
IdGenerator) en un use case `CloneProfileFromSeed` non spécifique à OpenCode, pour dupliquer un
|
||||
profil Claude/Codex avec un nom + `model` en override. Ne PAS laisser le frontend miner l'id
|
||||
(romprait la discipline IdGenerator déjà en place).
|
||||
2. Backend : catalogue de modèles Claude/Codex — aucune API fiable côté CLI, donc liste statique
|
||||
curée (même esprit que `static_fallback_catalogue()` d'OpenCode), exposée par commande Tauri
|
||||
infaillible (`list_claude_models`/`list_codex_models` ou générique par `structuredAdapter`).
|
||||
Le frontend garde toujours un champ de saisie manuelle en repli (liste jamais garantie
|
||||
exhaustive).
|
||||
3. Frontend : refonte `ProfilesSettings.tsx` en onglets Codex/Claude/OpenCode avec
|
||||
create/duplicate/edit/delete par onglet + `ModelSelect` searchable partagé ; simplifier
|
||||
`FirstRunWizard` pour ne créer qu'un profil par défaut par provider détecté, avec renvoi vers
|
||||
Settings pour en ajouter d'autres.
|
||||
|
||||
## Découpage de livraison
|
||||
DevBackend (use case + catalogues + commandes, petit lot, zéro migration) → DevFrontend (refonte
|
||||
Settings + first-run simplifié) → QA (créer 2 profils Claude modèles différents + 2 Codex, assigner
|
||||
à des agents distincts, vérifier le bon modèle atteint la CLI au lancement, non-régression
|
||||
OpenCode) → Git (branche feature unique, lot petit et couplé).
|
||||
@ -1,25 +0,0 @@
|
||||
---
|
||||
name: reconcile-live-state-implemented-feature-branch
|
||||
description: memory note reconcile-live-state-implemented-feature-branch
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
title: Réconciliation du live-state au reboot — implémentée (feature/reconcile-live-state)
|
||||
type: project
|
||||
description: Le chantier ReconcileLiveState (3 lots) est implémenté et vert (1623 tests), non committé ; détail des fichiers et de l'arbitrage project_id/provider.
|
||||
---
|
||||
|
||||
Implémenté le 2026-06-23 sur `feature/reconcile-live-state` (ticket Main a7fcb5e4, dont le rendez-vous `idea_reply` a expiré pendant le build — résultat consigné ici). **Non committé** (Git tranche). Cadrage : [[live-state-reboot-reconciliation-design]].
|
||||
|
||||
**Résultats réels** : `cargo test --workspace` = **1623 passed, 0 failed**. `cargo clippy --workspace --all-targets` = 0 erreur, aucun warning sur le code ajouté (warnings restants tous pré-existants).
|
||||
|
||||
**Lot 1 (domaine, `crates/domain/src/live_state.rs`)** : `LiveState::reconcile_orphans(is_live, now_ms) -> Vec<LiveEntry>` pure (ne mute pas self). Orphelin = status ∈ {Working,Waiting,Blocked} ET !is_live → réécrit status=Idle, intent gardé, ticket=None, last_delegation=None, progress=Some(`STALE_AT_RESTART_MARKER`), updated_at_ms=now. Const pub `STALE_AT_RESTART_MARKER = "(stale — session not running at restart)"`. +4 tests.
|
||||
|
||||
**Lot 2 (application, nouveau `crates/application/src/workstate/reconcile.rs`)** : use case `ReconcileLiveState` sur `LiveStateStore`+`LiveAgentRegistry`(ISP)+`Clock` ; `execute(ReconcileLiveStateInput{project_id})` charge → reconcile_orphans → upsert par ligne. +3 tests. Exporté via workstate/mod.rs + application/lib.rs.
|
||||
|
||||
**Lot 3 (app-tauri, `state.rs`+`commands.rs`)** : provider par-root `AppReconcileLiveState` (résout root via `ProjectStore::load_project`, `FsLiveStateStore::new(&root)`, registre = `LiveSessions` existant). Champ `reconcile_live_state` sur AppState. Hook best-effort dans `open_project` après `reconcile_layouts`. **Acte système** : écrit le port `LiveStateStore` directement, jamais via `OrchestratorCommand::SetWorkState` → self-only de `idea_workstate_set` préservé par construction.
|
||||
|
||||
**Arbitrage à valider QA/Architect** : la résolution project_id→root se fait au composition root (le store est root-bound), donc `ReconcileLiveState::execute` reçoit bien `ReconcileLiveStateInput{project_id}` (conforme Lot 2 + hook Lot 3 à la lettre) mais ne relit pas project_id dans le flux pur (`_input`). Variante sans ce param redondant = ajustement trivial si souhaité.
|
||||
|
||||
**Fichiers (6)** : domain/src/live_state.rs ; application/src/workstate/reconcile.rs (nouveau) ; application/src/workstate/mod.rs ; application/src/lib.rs ; app-tauri/src/state.rs ; app-tauri/src/commands.rs.
|
||||
@ -1,39 +0,0 @@
|
||||
---
|
||||
name: resume-after-appimage-rebuild-mcp-e2e
|
||||
description: memory note resume-after-appimage-rebuild-mcp-e2e
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
name: resume-after-appimage-rebuild-mcp-e2e
|
||||
description: Point de reprise — programme live-state CLOS+RELEASÉ (0.3.0), discordance .gitignore D19-4 TRANCHÉE. Prochain chantier = validation MCP e2e UX. Chantiers restants priorisés.
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Reprise — état au 2026-06-22 (run a6ced819)
|
||||
|
||||
## Où on en est
|
||||
- **Programme live-state / persistance CLOS et RELEASÉ** : `develop` @ `36be0cb` (LS8), `main` @ `29232dd` = `release(0.3.0): intègre develop dans main`. Détail : [[live-state-persistence-program-closed-ls8]]. Doc : `docs/LS8-live-state-persistence-closure.md` + `ARCHITECTURE.md` §21.
|
||||
- **AppImage rebuildée + tournante** : `IdeA_0.3.0_amd64.AppImage` (le nom n'est plus 0.1.0). Le binaire live embarque tout le programme ; 6 ponts MCP connectés/ESTAB observés → point 1 du chantier e2e (agent voit ses outils MCP sans action manuelle) déjà satisfait en réel. Recette rebuild (rappel) : `npm --prefix frontend run build` puis depuis `crates/app-tauri/` `APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 ../../frontend/node_modules/.bin/tauri build --bundles appimage` ; remplacer l'AppImage installée → relancer.
|
||||
- **Discordance .gitignore ↔ D19-4 : TRANCHÉE** (par l'utilisateur) et exécutée par Git → commit `47b3806` sur `develop` (`chore(gitignore): désuivre .ideai/conversations/`). Périmètre réel : seul `.ideai/conversations/` était discordant (16 fichiers suivis, 8 handoff.md + 8 log.jsonl) ; `.ideai/run/` et `.ideai/live-state.json` étaient déjà ignorés/propres. Désuivis (rm --cached, conservés sur disque) + règle ajoutée `.gitignore:58`. Plus une décision en attente.
|
||||
|
||||
## Prochain chantier (priorité 1) : VALIDATION MCP END-TO-END UX
|
||||
Objectif = valider/durcir en situation RÉELLE le parcours inter-agents (le code est probablement bon, Bugs 1→7 corrigés cf. [[mcp-bridge-and-delegation-runtime-notes]], mais ces bugs ne sont apparus qu'en live). À vérifier sur l'AppImage 0.3.0 :
|
||||
1. Un agent lancé par IdeA voit ses outils MCP sans action manuelle. (déjà OK observé)
|
||||
2. Délégation vers agent FROID et vers agent BACKGROUND (node_id None) : tâche bien écrite dans le PTY, pas de 1er tour perdu, pas de `Busy` fantôme après interruption/annulation (Bugs 3/4/6/7).
|
||||
3. Un `ask` sans réponse ne wedge pas la connexion du demandeur (Bug 5).
|
||||
4. Profils Claude/Codex utilisent MCP par défaut ; fallback fichier+prose cohérent sinon.
|
||||
5. Observabilité UI des délégations/replies (aujourd'hui opaque) — sujet UX.
|
||||
|
||||
**CONTRAINTE MÉTHODO** : NE PAS réparer/valider le système inter-agents VIA le système inter-agents (`idea_ask_agent`). Piloter via les **subagents natifs (outil Agent)**, et demander à l'utilisateur de faire tourner l'AppImage + observer (Main ne peut pas valider seul depuis l'intérieur). Diag live : `ss -xp | grep idea-mcp` (ponts connectés) ; `~/.claude/projects/<encoded-run-dir>/*.jsonl` (transcript ; pas de nouveau fichier = tâche jamais soumise).
|
||||
|
||||
## Autres chantiers restants (depuis [[remaining-work-idea-agent-control-ide]])
|
||||
- **Auto-update mémoire/contexte EN COURS de session** (aujourd'hui injection au lancement seulement) — priorité 1.
|
||||
- **Multi-fenêtres / déplacement d'onglet** du registre de sessions — priorité 2 (UI).
|
||||
- Optionnels différés : activation réelle du seam LLM de handoff (contrat figé ADR LS5, défaut heuristique) ; sweep périodique de rotation (idempotent, non câblé).
|
||||
|
||||
## Friction outillage notée (par Git, sans incidence résultat)
|
||||
Le `settings.local.json` du run dir a un `deny` qui bloque Edit/Write et certaines redirections Bash pour les agents en run dir isolé ; Git a dû éditer `.gitignore` via `tee -a`. À assouplir si on veut des éditions de fichiers propres côté run dir.
|
||||
|
||||
## Contrainte d'écriture (rappel)
|
||||
Main + agents en run-dir isolé ne peuvent PAS écrire l'arbre du project root (docs/, ARCHITECTURE.md, .ideai/memory/*.md fichiers) — permissions déniées. Mémoire IdeA : outil `idea_memory_write` (create/replace par slug ; pas de delete). Suppression fichiers mémoire / édition MEMORY.md / CLAUDE.md / .gitignore du project root : passer par **Git**.
|
||||
42
.ideai/memory/sandbox-eperm-bind-false-green-web-server.md
Normal file
42
.ideai/memory/sandbox-eperm-bind-false-green-web-server.md
Normal file
@ -0,0 +1,42 @@
|
||||
---
|
||||
name: sandbox-eperm-bind-false-green-web-server
|
||||
description: memory note sandbox-eperm-bind-false-green-web-server
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
name: sandbox-eperm-bind-false-green-web-server
|
||||
description: Les sandboxes de DevBackend et QA bloquent TcpListener::bind (EPERM) ; tout `cargo test` sur web-server/app-tauri y rend un VERT QUI NE PROUVE RIEN. Vérifier hors sandbox.
|
||||
metadata:
|
||||
type: reference
|
||||
---
|
||||
# Faux vert : `TcpListener::bind` interdit dans les sandboxes agents
|
||||
|
||||
## Le fait
|
||||
|
||||
Les environnements d'exécution de **DevBackend et de QA** refusent `TcpListener::bind("127.0.0.1:0")` avec `Operation not permitted (os error 1)`. Tout test qui ouvre un socket y est structurellement inexécutable.
|
||||
|
||||
Crates concernés : `web-server`, `app-tauri` (pont MCP, serveur embarqué).
|
||||
|
||||
## Pourquoi c'est dangereux, pas juste gênant
|
||||
|
||||
Le 2026-07-16, ce piège s'est refermé **deux fois dans la même journée** :
|
||||
|
||||
1. **#68 B1** — DevBackend annonce « 57 passed ». En réalité le test `run_embedded_stop_shuts_down_accept_loop` sortait en silence sur EPERM via un repli, et le test du core partagé basculait sur un dispatch in-process. Rejoué **hors sandbox** : échec réel, révélant un **vrai bug produit** — `run_embedded` ne réconciliait pas le port effectif avec la config, donc `origin_allowed` comparait l'origine à `http://127.0.0.1:0` et un serveur embarqué sur port éphémère **rejetait toutes les requêtes API en 403**. Le trou n'avait jamais été vu parce que rien ne consommait `run_embedded`.
|
||||
2. **#72** — même schéma, cette fois signalé honnêtement par DevBackend (« 63 passed; 2 failed » sur EPERM) après consigne explicite.
|
||||
|
||||
Un repli silencieux sur EPERM transforme un test en décoration : il passe sans rien exercer, et masque la classe de bug qu'il était censé attraper.
|
||||
|
||||
## La règle
|
||||
|
||||
- **Aucun repli EPERM silencieux.** Un test qui ne peut pas s'exécuter doit **échouer visiblement** ou être `#[ignore]` explicite avec sa raison — jamais « passer ».
|
||||
- **Tout vert sur `web-server`/`app-tauri` doit être produit hors sandbox** (`dangerouslyDisableSandbox: true` côté Main, qui n'a pas la restriction). Ne jamais accepter un vert sandboxé comme preuve sur ces crates.
|
||||
- DevBackend et QA doivent **dire ce qu'ils ont pu exécuter et ce qu'ils n'ont pas pu**, plutôt que de rendre un chiffre global.
|
||||
- Les `#[ignore = "requires local socket bind permission"]` légitimes (ex. `mcp_bridge::tests::end_to_end_over_real_loopback`) se vérifient en les **lançant** hors sandbox avec `--ignored`, pas en raisonnant dessus.
|
||||
|
||||
## Principe général
|
||||
|
||||
Ne pas confondre « les tests sont verts » et « le code marche ». Le vert d'un environnement contraint ne dit rien du produit. Cette leçon vaut au-delà du bind : un environnement qui ne peut pas exercer un chemin ne peut pas le valider.
|
||||
|
||||
Lien : [[appimage-build-no-strip-relr-dyn-fix]] (autre piège d'environnement de cette machine),
|
||||
[[rendezvous-600s-cap-too-short-heavy-tasks]].
|
||||
@ -0,0 +1,67 @@
|
||||
---
|
||||
name: ticket101-cross-talk-multi-project-rootcause
|
||||
description: memory note ticket101-cross-talk-multi-project-rootcause
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
slug: ticket101-cross-talk-multi-project-rootcause
|
||||
title: "Ticket #101 — défaut d'isolation multi-projet (registres runtime globaux par AgentId)"
|
||||
type: reference
|
||||
description: Cause racine du cross-talk entre projets ouverts simultanément (branche hybride wear-os + notification de tâche backend perdue) : les stores disque IdeA sont scoppés par projet, mais plusieurs registres mémoire runtime critiques restent indexés par AgentId seul, sans re-mint des UUID à l'ouverture. Plan de correction figé en 6 lots (clé RuntimeAgentKey).
|
||||
---
|
||||
|
||||
# Ticket #101 — défaut d'isolation multi-projet (cause racine)
|
||||
|
||||
## Symptômes (2 manifestations, même défaut)
|
||||
- **A — contamination du contexte d'inférence** : un agent a créé une pseudo-branche `feature/ticket91-wear-os-watch-sync` (ticket #91 purement front) où le suffixe `wear-os-watch-sync` appartient à l'AUTRE projet de l'utilisateur. Le nom n'apparaît dans aucun fichier `.ideai/` du projet IdeA → contamination au niveau du contexte d'inférence runtime (conversation injectée à l'agent Git mélangeait les projets). Preuve topo préservée : `main` divergé de `develop` (da907b8 vs 6a87c46), `feature/ticket99-agent-model-configuration` créée depuis main au lieu de develop.
|
||||
- **B — notification de tâche backend perdue / agent qui s'arrête** (sujet original #101) : un agent OpenCode lance `idea_run_in_background` puis s'arrête, sans retour de notification garanti.
|
||||
|
||||
## Cause racine (Architect, 2026-07-25)
|
||||
Stores disque **correctement scoppés par projet** (mémoire, contexte, handoff, live-state lus depuis `input.project.root` ; agents persistés dans `.ideai/agents.json` par root projet). MAIS les agents **ne re-mint pas leurs UUID à l'ouverture** → deux projets (surtout si l'un est une copie) peuvent porter les **mêmes `AgentId`**.
|
||||
|
||||
Plusieurs **registres mémoire runtime restent globaux, indexés par `AgentId` seul** :
|
||||
- ConversationRegistry global + `ConversationId` dérivé des UUID agents seuls — `crates/domain/src/conversation.rs:71`, `crates/infrastructure/src/conversation/mod.rs:41`, orchestrateur `crates/application/src/orchestrator/service.rs:2192`.
|
||||
- Sessions PTY/structured retrouvées par `agent_id` seul — `crates/application/src/terminal/registry.rs:182,437` ; réutilisation session `service.rs:2293,2368`.
|
||||
- Verrous ask, busy-state, liveness, délégations différées par `AgentId` seul — `service.rs:418`, `crates/infrastructure/src/input/mod.rs:47`.
|
||||
- Inbox/mailbox par `AgentId` seul — `crates/domain/src/inbox.rs:68,156`, `input/mod.rs:1052`, `crates/infrastructure/src/mailbox/mod.rs:44`.
|
||||
- Wake par `AgentId` seul — `crates/application/src/orchestrator/wake.rs:87`, provider `crates/backend/src/lib.rs:687`.
|
||||
|
||||
→ Un agent du projet courant peut se rattacher à la conversation/session/inbox d'un autre projet (collision d'UUID) : contamination d'inférence (A) ET complétion livrable/bloquée/réveillant la mauvaise session (B).
|
||||
|
||||
## Pour B : runtime vs modèle
|
||||
La chaîne sink→`project_id`→wake est correcte jusqu'au bridge (`crates/infrastructure/src/background_task/sink.rs:23,142` ; `crates/backend/src/lib.rs:2228` recharge le projet par `project_id` puis `wake_agent`). Le défaut réapparaît juste après (inbox/mailbox/busy/session par AgentId seul). **Runtime IdeA suspecté en premier.** Le modèle GLM 5.2 n'est l'hypothèse principale que si les logs prouvent (pour le bon `project_id`) : enqueue + wake + `BackgroundTaskCompletionDelivered` émis sans reprise utile. Traces : `lib.rs:2238`, `wake.rs:93`.
|
||||
|
||||
## Plan de correction (6 lots, figé)
|
||||
1. Introduire `RuntimeAgentKey { project_id, agent_id }` ; interdire toute map app-wide indexée par `AgentId` seul.
|
||||
2. Propager la clé dans `AgentInbox`, `InputMediator`, `AgentMailbox`, busy/liveness/deferred, wake, session lookup, ask-locks. **Correctif structurel commun à A et B.**
|
||||
3. Qualifier les conversations par projet : `ConversationId` + `ConversationRegistry` intègrent `ProjectId`.
|
||||
4. Requalifier `TerminalSessions`/`StructuredSessions` par `(project_id, agent_id)` ; `AppWakeSessionProvider` refuse toute session vivante d'un autre projet.
|
||||
5. Audit des autres états mémoire similaires (`session_limit`, tables de reprise/verrous par agent) pour éviter une demi-correction.
|
||||
6. Télémétrie `project_id` explicite sur les logs diag critiques de wake/routage.
|
||||
|
||||
## Invariants
|
||||
- Sources de contexte sur disque restent root-scopées (ne pas régresser).
|
||||
- Templates/profils globaux restent globaux produit — ne doivent pas devenir vecteurs de session/conversation partagée.
|
||||
- Un projet non-actif doit continuer à recevoir ses wakes et complétions.
|
||||
- Pas de régression OpenCode/Codex/Claude (correctif transverse runtime, pas moteur-spécifique).
|
||||
- Aucun nouveau DTO frontend pour la correction minimale.
|
||||
|
||||
## QA — critère de vérité
|
||||
Test d'intégration **non-cross-talk** : 2 projets ouverts simultanément contenant **volontairement les mêmes `AgentId`** :
|
||||
- délégation dans projet A ne réutilise jamais une session/conversation vivante de projet B ;
|
||||
- complétion `(project A, agent X)` n'entre ni dans l'inbox ni dans la session de `(project B, agent X)` ;
|
||||
- le wake d'un projet non-actif fonctionne quand même ;
|
||||
- une collision d'ids qui échouait avant devient verte sur PTY, structured et background wake.
|
||||
|
||||
## Hors périmètre
|
||||
- #91 (popup de notification) : purement front, indépendant du défaut runtime.
|
||||
- Remint systématique des AgentId à l'ouverture : piste complémentaire non retenue dans le fix minimal (la clé runtime scellée par projet rend la collision inoffensive même sans remint).
|
||||
|
||||
## Topologie
|
||||
- Branche de travail à créer pour le fix (Git décidera). Base `develop` (6a87c46). `main`/`feature/ticket99-agent-model-configuration` divergent sur da907b8 (preuves préservées, à nettoyer après enquête).
|
||||
|
||||
## Lié
|
||||
- #91 (relatesTo) : popup de notification — front pur.
|
||||
- Mémoire `background-tasks-first-class-design` + `b8-command-runner-pty-framing` : design du flux de complétion (le défaut est en aval du sink).
|
||||
- Mémoire `mcp-bridge-and-delegation-runtime-notes` : règle rebuild AppImage (le binaire qui tourne = AppImage, pas les sources).
|
||||
10
.ideai/memory/ticket103-network-permission-ux-surface.md
Normal file
10
.ideai/memory/ticket103-network-permission-ux-surface.md
Normal file
@ -0,0 +1,10 @@
|
||||
---
|
||||
name: ticket103-network-permission-ux-surface
|
||||
description: Stable UX convention for agent network permissions in IdeA.
|
||||
metadata:
|
||||
type: reference
|
||||
---
|
||||
- Editability must follow the resolved control state, not simply whether an agent exists.
|
||||
- Non-launched agents stay editable unless a runtime lock is explicitly present.
|
||||
- Read-only messaging should be explicit only for active locked runtimes, especially external/uninspectable runtimes.
|
||||
- Effective policy labels must not be used as a proxy for editability.
|
||||
23
.ideai/memory/ticket13-f0-frontend-transport-inventory.md
Normal file
23
.ideai/memory/ticket13-f0-frontend-transport-inventory.md
Normal file
@ -0,0 +1,23 @@
|
||||
---
|
||||
name: ticket13-f0-frontend-transport-inventory
|
||||
description: Résultat de l'inventaire B0/F0 frontend du chantier client/serveur #13 — la frontière gateways transport-neutres existe déjà, F1 = ajout d'adapters HTTP+WS.
|
||||
metadata:
|
||||
type: reference
|
||||
---
|
||||
Inventaire B0/F0 (ticket #13 server/client mode), côté frontend TS/React. Doc : `docs/ticket13-f0-frontend-transport-inventory.md`.
|
||||
|
||||
**Constat clé** : la frontière « gateways TS transport-neutres » du plan est DÉJÀ réalisée et testée.
|
||||
- `src/ports/index.ts` = 21 gateways sans Tauri ; toute la couche `features/`+`app/` en dépend via DI (`useGateways()`).
|
||||
- `src/adapters/*` = seul lieu important `@tauri-apps/api`.
|
||||
- Garde L1 `src/app/no-direct-invoke.test.ts` casse la CI si un fichier hors `adapters` importe Tauri / appelle `invoke(`.
|
||||
- `src/app/di.tsx` `resolveGateways()` bifurque déjà Tauri vs mock → F1 = ajouter `createHttpWsGateways()` (3ᵉ impl).
|
||||
|
||||
**Donc F1 = écrire un 2ᵉ jeu d'adapters derrière des ports inchangés, aucun composant métier à réécrire.**
|
||||
|
||||
**Flux Channel (→ WebSocket)** : (1) `terminal.ts` PTY, (2) `agent.ts` PTY agent (réutilise `makeTerminalHandle`), (3) `ticket.ts` `sendTicketChat` `Channel<ReplyChunk>`. Tous modélisés côté port par callback `onData`/`onChunk`. Le contrat PTY WS du carnet mappe 1-pour-1 sur `TerminalHandle` (write/resize/detach/close, detach≠close, scrollback au reattach) → port inchangé pour F3. `TerminalView.tsx` ne connaît que le port.
|
||||
|
||||
**Event portable** : `system.onDomainEvent("domain://event")` (bus domaine) → WS serveur→client.
|
||||
|
||||
**Desktop-only à cadrer** : `system.pickFolder` (dossier = machine serveur ≠ client web → file-picker serveur), `window.ts` (WebviewWindow OS) et `focusedProject.ts` (multi-fenêtres OS) probablement hors V1 web. `uiPreferences` (localStorage) marche tel quel.
|
||||
|
||||
Convention DTO à préserver côté adapter HTTP : commandes snake_case, payloads camelCase souvent enveloppés `{ request: {...} }`.
|
||||
17
.ideai/memory/ticket13-f1-http-ws-adapter-delivered.md
Normal file
17
.ideai/memory/ticket13-f1-http-ws-adapter-delivered.md
Normal file
@ -0,0 +1,17 @@
|
||||
---
|
||||
name: ticket13-f1-http-ws-adapter-delivered
|
||||
description: Le 3e jeu d'adapters frontend (HTTP request/response + squelette WebSocket) du chantier client/serveur #13 est livré et vert, derrière les ports inchangés.
|
||||
metadata:
|
||||
type: reference
|
||||
---
|
||||
Ticket #13 lot F1 livré sur feature/ticket13-server-client-mode. Nouveau dossier `frontend/src/adapters/http/` = 3e implémentation des gateways, à côté de Tauri (desktop) et mock.
|
||||
|
||||
**Fichiers** : `httpInvoker.ts` (POST /api/invoke {command,args}, ErrorDto→GatewayError, fetch injectable), `frames.ts` (contrat frames WS B0 + base64), `wsLiveClient.ts` (squelette WS multiplexé : corrélation id↔replyTo, routage terminal.output par session, dispatch event.domain), `requestResponseGateways.ts` (13 gateways R/R, commandes/enveloppes IDENTIQUES aux adapters Tauri), `streamGateways.ts` (HttpSystem/Agent/Ticket/Terminal + makeWsTerminalHandle detach≠close), `unsupported.ts` (Web{Window,FocusedProject,Remote}Gateway, code UNSUPPORTED_ON_WEB), `index.ts` (createHttpWsGateways(config?), endpoints via window.location). Tests : httpInvoker.test.ts, wsLiveClient.test.ts.
|
||||
|
||||
**Seam DI** : `app/di.tsx` → `resolveTransport()` 3-way (mock > http > tauri), web sélectionné par `VITE_TRANSPORT="http"`. Tauri reste défaut (desktop inchangé).
|
||||
|
||||
**Décision de contrat clé (à confirmer DevBackend)** : transport RPC générique `POST /api/invoke {command,args}` choisi PLUTÔT que l'arbre REST du brouillon B0 — préserve 1:1 tous les DTO Tauri, zéro divergence, bascule REST future ne touche que httpInvoker.ts. Autres points à trancher : placement token WS (pas en URL ; navigateur ne peut pas fixer d'en-tête upgrade), forme réponse terminal.open/agent.launch (ack terminal.attached avec session.sessionId), projectId absent du port openTerminal.
|
||||
|
||||
**Reporté F3/B5/B6** (TODO(F3/B5)) : round-trip xterm réel, reconnexion/backpressure, replay seq/gap, sink chat par-session pour sendTicketChat, agents structurés. Pas de serveur avant B3/B4.
|
||||
|
||||
État : build vert (tsc+vite), garde no-direct-invoke verte, 77 fichiers/724 tests verts. Voir [[ticket13-f0-frontend-transport-inventory]].
|
||||
19
.ideai/memory/ticket13-f2-web-readonly-client-delivered.md
Normal file
19
.ideai/memory/ticket13-f2-web-readonly-client-delivered.md
Normal file
@ -0,0 +1,19 @@
|
||||
---
|
||||
name: ticket13-f2-web-readonly-client-delivered
|
||||
description: Le client web read-only (pairing cookie, liste projets, ouverture read-only + snapshot work-state) du chantier client/serveur #13 est livré et vert.
|
||||
metadata:
|
||||
type: reference
|
||||
---
|
||||
Ticket #13 lot F2 livré sur feature/ticket13-server-client-mode. Clôture frontend du premier incrément livrable (B0→B4/F2).
|
||||
|
||||
**Nouveau** : `adapters/http/webSession.ts` (WebSession : flag localStorage « paired » — PAS le cookie HttpOnly ; `pair(code)`→POST /api/pair ; `notifyUnauthorized()` clear+notify ; singleton `getWebSession()`), `features/web/` (PairingScreen, WebWorkspace read-only, WebApp gate). Tests : webSession.test.ts, WebApp.test.tsx.
|
||||
|
||||
**Modifié** : httpInvoker (credentials same-origin + callback onUnauthorized sur 401), http/index.ts (câble onUnauthorized→webSession), app/main.tsx (monte <WebApp/> si resolveTransport()==="http", desktop inchangé).
|
||||
|
||||
**Flux** : non-paired→PairingScreen ; pair OK (cookie HttpOnly posé serveur)→WebWorkspace ; 401 d'un /api/invoke→retour pairing ; « se déconnecter »=clear flag local (révocation serveur=B8). Cookie jamais lisible en JS (HttpOnly) : on se fie au 200 + flag de routage.
|
||||
|
||||
**Read-only** : WebWorkspace n'appelle QUE list_projects, open_project, get_project_work_state (via gateways DI). N'appelle PAS onDomainEvent/health/firstRunState → aucune commande hors-allowlist, pas de WS (live update = F3/B5, snapshot ponctuel pour l'instant).
|
||||
|
||||
**À confirmer B4** : get_project_work_state dans l'allowlist ; open_project sans effet de bord dangereux en read-only ; 401 (pas 403) sur cookie manquant ; code HTTP mauvais code /api/pair (401/403 → « Code d'appairage invalide »).
|
||||
|
||||
Build vert, garde no-direct-invoke verte, 79 fichiers/736 tests verts, desktop inchangé. Suite de [[ticket13-f1-http-ws-adapter-delivered]] ; inventaire [[ticket13-f0-frontend-transport-inventory]].
|
||||
19
.ideai/memory/ticket13-f3-xterm-websocket-delivered.md
Normal file
19
.ideai/memory/ticket13-f3-xterm-websocket-delivered.md
Normal file
@ -0,0 +1,19 @@
|
||||
---
|
||||
name: ticket13-f3-xterm-websocket-delivered
|
||||
description: L'adapter WS terminal (round-trip xterm, reconnexion+replay, états connexion) du chantier client/serveur #13 est finalisé et vert côté frontend.
|
||||
metadata:
|
||||
type: reference
|
||||
---
|
||||
Ticket #13 lot F3 livré sur feature/ticket13-pty-websocket. Finalise l'adapter WS terminal depuis le squelette F1. Travail 100% dans frontend/src/adapters/http/ ; port TerminalGateway/TerminalHandle et TerminalView INCHANGÉS.
|
||||
|
||||
**wsLiveClient.ts** : machine d'état connexion (connecting/connected/reconnecting/closed, getConnectionState()+onConnectionStateChange), reconnexion auto (backoff, setTimeout injectable) → re-attach_terminal avec lastSeq + repaint scrollback borné + notices « déconnecté »/« reconnecté » écrites dans xterm via le sink. Suivi des sessions terminales (map `terminals`) pour le replay. Routage terminal.status exited → notice + onStatus + untrack. openTerminal/attachTerminal/detachTerminal/closeTerminalSession haut-niveau. API bas-niveau F1 (setOutputSink/send/domain events) conservée pour agent/system gateways.
|
||||
**streamGateways.ts** : HttpTerminalGateway délègue aux nouvelles méthodes ; makeWsTerminalHandle.detach→detachTerminal (untrack, PTY vivant), close→closeTerminalSession (tue).
|
||||
**frames.ts** : AttachedPayload.status? + StatusPayload.
|
||||
|
||||
**Contrat B5 (server.rs) confirmé** : frames terminal.open{cwd,rows,cols} (pas de projectId)/attach{sessionId,rows,cols,lastSeq}/input{sessionId,bytesBase64}/resize/detach/close/ping ↔ terminal.attached{session,scrollback:[{seq,bytesBase64}],nextSeq,status,gap,assignedConversationId}/output{sessionId,seq,bytesBase64}/status{sessionId,status,exitCode}/error/pong. Ack unifié terminal.attached. Scrollback = 1 entrée seq:0 (tous octets) ou vide.
|
||||
|
||||
**Écarts B5 à arbitrer** : (1) pas de replay delta — le serveur rejoue TOUT le scrollback, lastSeq ne sert qu'au flag gap ⇒ duplication possible à la reconnexion (conforme « V1 scrollback borné »). (2) multi-onglets « dernier gagne » SILENCIEUX — l'attachement évincé ne reçoit aucune frame (pas de crash, mais pas d'indication). (3) indication d'état = notices dans xterm (port inchangé).
|
||||
|
||||
**Tests** : terminalGateway.test.ts (round-trip), wsLiveClientReconnect.test.ts (états/reconnexion/exited). Build vert, garde no-direct-invoke verte, 81 fichiers/743 tests verts, desktop inchangé.
|
||||
|
||||
**Bloqueur run live** (dette carnet, hors F3) : `idea --serve` ne sert pas les assets web same-origin ⇒ app web pas lançable en navigateur tant que le lot « servir dist/ » n'est pas fait. Suite de [[ticket13-f1-http-ws-adapter-delivered]], [[ticket13-f2-web-readonly-client-delivered]].
|
||||
19
.ideai/memory/ticket13-f4-web-agent-surface-delivered.md
Normal file
19
.ideai/memory/ticket13-f4-web-agent-surface-delivered.md
Normal file
@ -0,0 +1,19 @@
|
||||
---
|
||||
name: ticket13-f4-web-agent-surface-delivered
|
||||
description: L'agent CLI web (agent.launch → terminal.attached, réattache sans relance, cellule agent réutilisant TerminalView) du chantier client/serveur #13 est livré et vert côté frontend.
|
||||
metadata:
|
||||
type: reference
|
||||
---
|
||||
Ticket #13 lot F4 livré sur feature/ticket13-pty-websocket. Rend la surface agent fonctionnelle en mode web via les gateways DI ; CLI serveur, web = affichage.
|
||||
|
||||
**Adapter** : wsLiveClient.launchAgent(params) réutilise attachInternal de F3 → frame agent.launch, ack unifié terminal.attached, session trackée dans la map `terminals` (reconnexion/replay/exited comme un terminal), renvoie {sessionId, scrollback, assignedConversationId, status}. HttpAgentGateway.launchAgent → ws.launchAgent (pose assignedConversationId sur le handle) ; HttpAgentGateway.reattach → ws.attachTerminal (frame terminal.attach, PAS de relance). Chemin bas-niveau F1 dupliqué supprimé.
|
||||
|
||||
**UI (câblage, pas de nouveau composant terminal)** : features/web/WebAgentCell.tsx réutilise TerminalView (agentMode) avec agent gateway DI comme open=launchAgent/reattach=reattach, persiste sessionId. WebWorkspace : affordance « Ouvrir » par agent du snapshot work-state → monte WebAgentCell.
|
||||
|
||||
**Contrat B6 (server.rs) confirmé, aucun écart** : agent.launch payload plat camelCase {projectId,agentId,nodeId,rows,cols,conversationId} → ack terminal.attached{assignedConversationId}. Agent structuré → erreur UNSUPPORTED (canal PTY-only) surfacée par la bannière TerminalView. Réattache = terminal.attach (no respawn). Singleton guard AGENT_ALREADY_RUNNING déjà géré par TerminalView.
|
||||
|
||||
**Points UI à signaler** : (1) l'affordance liste les agents du snapshot work-state ; lister tous les agents exigerait list_agents sur l'allowlist B4. (2) write-portal (injection délégation) NON câblé en web V1 (affichage + frappe seulement). (3) WebAgentCell ne gère pas de nœud layout.
|
||||
|
||||
**Tests** : adapters/http/agentGateway.test.ts (launch/assignedConversationId/reattach/input/output/resize/UNSUPPORTED/NOT_FOUND), WebApp.test.tsx (+ouverture cellule). Build vert, garde no-direct-invoke verte, 82 fichiers/749 tests verts, desktop inchangé.
|
||||
|
||||
**Bloqueur run live** (dette carnet, hors F4) : `idea --serve` ne sert pas les assets web same-origin ⇒ round-trip navigateur pas validable tant que le lot « servir dist/ » n'est pas fait. Suite de [[ticket13-f3-xterm-websocket-delivered]], [[ticket13-f1-http-ws-adapter-delivered]], [[ticket13-f2-web-readonly-client-delivered]].
|
||||
17
.ideai/memory/ticket13-f5-web-live-surfaces-delivered.md
Normal file
17
.ideai/memory/ticket13-f5-web-live-surfaces-delivered.md
Normal file
@ -0,0 +1,17 @@
|
||||
---
|
||||
name: ticket13-f5-web-live-surfaces-delivered
|
||||
description: Les surfaces live web (workstate live via event.domain, background tasks cancel/retry, inbox, re-synchro au reconnect) du chantier client/serveur #13 sont livrées et vertes.
|
||||
metadata:
|
||||
type: reference
|
||||
---
|
||||
Ticket #13 lot F5 livré sur feature/ticket13-pty-websocket. Rend les surfaces live fonctionnelles en mode web.
|
||||
|
||||
**Réutilisation clé** : le hook desktop transport-neutre `features/workstate/useProjectWorkState` (refresh du read-model sur event.domain) est réutilisé TEL QUEL — c'est lui qui donne la parité live. PAS de réutilisation de ProjectWorkStatePanel (dépend de useLayout + attach/stop-vers-cellule, spécifiques au grid desktop, hors read-only). WebWorkspace rend une vue lean : agents live/idle/busy, background tasks (Cancel/Retry via workState gateway), inbox par agent, + cellule agent F4.
|
||||
|
||||
**Adapter** : wsLiveClient.needsReconnect() = terminals.size>0 OU domainEventHandler!=null → la reconnexion marche aussi pour un abonnement live sans terminal (le handler domaine persiste à travers la reconnexion). Nouveau webLive.ts = singleton getWebLiveClient()/setWebLiveClient() (createHttpWsGateways enregistre le ws) exposant l'état de connexion au feature web SANS le mettre dans le port SystemGateway. Nouveau hook features/web/useLiveReconnect.ts : re-refresh du read-model sur transition reconnecting→connected (events manqués pendant coupure ; récupération = re-fetch complet du snapshot, pas de replay serveur).
|
||||
|
||||
**À confirmer B7** : (1) cancel_background_task/retry_background_task sur l'allowlist web write. (2) inbox surfacée via le read-model workstate, PAS via un flux notifications distinct (si B7 en a un, non câblé). (3) re-synchro = re-fetch complet (workstate = snapshot complet), pas de delta par event.
|
||||
|
||||
**Tests** : WebWorkspaceLive.test.tsx (event.domain→refresh, background render+cancel, reconnect re-sync), wsLiveClientReconnect (reconnexion pour abonnement domaine). Build vert, garde no-direct-invoke verte, 83 fichiers/753 tests verts, desktop inchangé.
|
||||
|
||||
**Bloqueur run live** (dette carnet, hors F5) : `idea --serve` ne sert pas les assets web same-origin. Suite de [[ticket13-f4-web-agent-surface-delivered]], [[ticket13-f3-xterm-websocket-delivered]], [[ticket13-f2-web-readonly-client-delivered]].
|
||||
54
.ideai/memory/ticket43-backend-b1-b4-qa-validation.md
Normal file
54
.ideai/memory/ticket43-backend-b1-b4-qa-validation.md
Normal file
@ -0,0 +1,54 @@
|
||||
---
|
||||
name: ticket43-backend-b1-b4-qa-validation
|
||||
description: memory note ticket43-backend-b1-b4-qa-validation
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
title: Validation QA backend B1-B4 du système de plugins #43
|
||||
type: reference
|
||||
description: Verdict QA du périmètre backend plugin B1-B4 sur feature/ticket43-plugin-system, tests ajoutés et limites sandbox constatées.
|
||||
---
|
||||
|
||||
# Validation QA backend B1-B4 du système de plugins #43
|
||||
|
||||
Sur `feature/ticket43-plugin-system`, QA a validé le périmètre backend B1-B4 sans modifier le frontend.
|
||||
|
||||
Tests/ajustements QA ajoutés :
|
||||
|
||||
- `crates/domain/tests/layout.rs` : les helpers de tests existants ignorent explicitement `LayoutNode::CustomPluginLayout(_)`, ce qui rétablit l'exhaustivité de compilation des tests domaine après l'ajout du layout plugin custom.
|
||||
- `crates/application/src/plugin/mod.rs` : tests in-memory des ports plugin pour vérifier :
|
||||
- catalogue runtime vide pour `Disabled`, `PendingUninstall`, `Invalid` ;
|
||||
- réconciliation MCP limitée aux plugins enabled + serveurs `autoStart`, identité `plugin:<pluginId>:<serverId>` et résolution sous `pluginRoot` ;
|
||||
- disable stoppe le MCP, publie `PluginDisabled`, retire le plugin du runtime catalog ;
|
||||
- uninstall stoppe le MCP, retire registry + package et publie `PluginUninstalled`.
|
||||
|
||||
Commandes vertes constatées :
|
||||
|
||||
```text
|
||||
cargo test -p application plugin --offline --no-fail-fast
|
||||
# 7 passed; 0 failed
|
||||
|
||||
cargo test -p domain -p application -p infrastructure -p backend -p app-tauri plugin --offline --no-fail-fast
|
||||
# plugin-filtered targeted suite green; application 7 plugin tests, domain 3 plugin tests,
|
||||
# serde roundtrip custom plugin layout, infrastructure 3 plugin tests, dto plugin filtered test all ok.
|
||||
|
||||
cargo test -p app-tauri --test dto_plugins --offline --no-fail-fast
|
||||
# 2 passed; 0 failed
|
||||
|
||||
cargo fmt --check
|
||||
# OK
|
||||
```
|
||||
|
||||
Workspace complet :
|
||||
|
||||
```text
|
||||
cargo test --workspace --offline --no-fail-fast -- --test-threads=1
|
||||
```
|
||||
|
||||
Résultat KO attendu dans ce sandbox, hors périmètre plugin :
|
||||
|
||||
- `-p infrastructure --lib` : 10 échecs `session::openai_compat::*` sur `bind: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }`.
|
||||
- `-p web-server --lib` : 2 échecs de bind `127.0.0.1:0 Operation not permitted` et 5 scénarios websocket/terminal recevant `error` au lieu de `terminal.attached`, cohérents avec restrictions loopback/PTY du sandbox.
|
||||
|
||||
Verdict : backend plugins B1-B4 validé QA avec réserve uniquement environnementale sur le workspace global.
|
||||
52
.ideai/memory/ticket43-plugin-system-final-qa-verdict.md
Normal file
52
.ideai/memory/ticket43-plugin-system-final-qa-verdict.md
Normal file
@ -0,0 +1,52 @@
|
||||
---
|
||||
name: ticket43-plugin-system-final-qa-verdict
|
||||
description: memory note ticket43-plugin-system-final-qa-verdict
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
title: Verdict QA final du ticket #43 système de plugins
|
||||
type: reference
|
||||
description: Validation finale QA de #43 après carnet v5, corrections F4/F3/B4 et exécutions réelles backend/frontend.
|
||||
---
|
||||
|
||||
# Verdict QA final du ticket #43 système de plugins
|
||||
|
||||
Branche validée : `feature/ticket43-plugin-system`.
|
||||
|
||||
Contexte : après verdict QA orange initial, Architect a figé le carnet v5 : `customPluginLayout` top-level canonique, `gitRepository` obligatoire en F3, `${appDataDir}` obligatoire en B4, et `agentSelected`/`terminalFocused`/`layoutCellFocused` + persistance backend state layout plugin acceptés comme dette v1.
|
||||
|
||||
Résultats réels exécutés par QA :
|
||||
|
||||
```text
|
||||
cargo test -p domain -p application -p infrastructure -p backend -p app-tauri plugin --offline --no-fail-fast
|
||||
# OK
|
||||
# application plugin: 9 passed
|
||||
# domain plugin: 3 passed
|
||||
# infrastructure plugin: 5 passed
|
||||
# custom_plugin_layout_roundtrips_with_opaque_state: ok
|
||||
|
||||
cd frontend && npm run typecheck
|
||||
# exit 0
|
||||
|
||||
cd frontend && npm test -- --run
|
||||
# Test Files 104 passed (104)
|
||||
# Tests 947 passed (947)
|
||||
```
|
||||
|
||||
Contrôles ciblés confirmés :
|
||||
|
||||
- Frontend `LayoutNode` inclut `{ type: "customPluginLayout"; node: CustomPluginLayoutCell }` top-level, sans contrat `LeafCell.pluginLayout`.
|
||||
- `LayoutGrid` route `customPluginLayout` vers `PluginLayoutCellView`.
|
||||
- `onStateChange`, `onOpenPlugins`, `onChooseAnotherLayout` sont câblés in-session (`setPluginLayoutState`, navigation settings plugins, remplacement par terminal).
|
||||
- `ProjectsView` câble `gitRepository` via `GitGateway.branches(active.id)` ; `agentSelected`, `terminalFocused`, `layoutCellFocused` restent explicitement `false` en dette v1.
|
||||
- Backend application substitue `${pluginRoot}` et `${appDataDir}` dans command/args/env/cwd des specs MCP plugin, avec test `reconcile_mcp_substitutes_app_data_dir_in_plugin_server_specs`.
|
||||
|
||||
Verdict QA : VERT pour merge local du ticket #43.
|
||||
|
||||
Dette v1 assumée :
|
||||
|
||||
- `agentSelected`, `terminalFocused`, `layoutCellFocused` non câblés, figés à `false` jusqu'à un lot focus/selection dédié.
|
||||
- Persistance backend du `state` de layout plugin non implémentée ; F4 validé en in-session selon arbitrage Architect.
|
||||
|
||||
Aucun nouveau blocage détecté dans les suites demandées.
|
||||
15
.ideai/memory/ticket54-f1-model-download-overlay-frontend.md
Normal file
15
.ideai/memory/ticket54-f1-model-download-overlay-frontend.md
Normal file
@ -0,0 +1,15 @@
|
||||
---
|
||||
name: ticket54-f1-model-download-overlay-frontend
|
||||
description: Overlay plein-cellule de préparation du serveur modèle local + progression (barre/%/bytes/source), corrélation factorisée, priorité de voile.
|
||||
metadata:
|
||||
type: reference
|
||||
---
|
||||
Ticket #54 livré et vert côté frontend (F1 = overlay, F2 = progression).
|
||||
|
||||
**Contrat** : `ModelServerStatus.downloading { downloadedBytes|totalBytes|percent|source: number|string|null }` (`frontend/src/domain/index.ts`), miroir exact de `ModelServerStatusDto` (`crates/app-tauri/src/events.rs`). Event `modelServerStatusChanged` passé tel quel — pas de mapping de désérialisation.
|
||||
|
||||
**Factorisation** dans `frontend/src/features/agents/modelServerLaunch.ts` : `correlateModelServerStatus` (chaîne `agentId→profileId→opencode.localModelServerId→serverId`), `modelServerOverlayText` (titre+gating de voile), `useModelServerLaunchState(projectId)` (source autonome pour LeafView), et F2 : `formatBytes` (SI base 1000 : o/Ko/Mo/Go) + `describeModelServerDownload` → `{percent(clamp 0..100 ou null=indéterminé), bytesLabel, source}` (null hors `downloading`). AgentsPanel réutilise le helper.
|
||||
|
||||
**Overlay** dans `LeafView`/`LayoutGrid.tsx` (`data-testid=model-server-overlay`, `zIndex CELL_Z.veil`) : titre + barre `role=progressbar` (aria-valuenow seulement en déterminé, sinon barre indéterminée via keyframe `model-server-indeterminate` dans `theme.css`) + label `"X % · A Mo / B Mo"` + ligne source HF. `starting`/`probing` = titre seul, pas de barre. **Priorité : voile modèle au-dessus** des voiles write-portal + F3 (les deux gatés sur `!modelServerOverlay`). Voir [[ticket4-overlay-composition-leafview]].
|
||||
|
||||
Tests : `LayoutGrid.modelServerOverlay.test.tsx` (F1+F2, dont multi-cellules & indéterminé) + unitaire pur `modelServerLaunch.test.ts`. Non-régression `src/features/agents src/features/layout` = 202 verts ; `npx tsc --noEmit` clean.
|
||||
@ -0,0 +1,19 @@
|
||||
---
|
||||
name: ticket56-visibleelsewhere-derives-from-layout
|
||||
description: Fix frontend du sélecteur d'agent : la désactivation « visible ailleurs » doit venir du layout courant, pas du dernier nodeId du live registry.
|
||||
metadata:
|
||||
type: reference
|
||||
---
|
||||
Bug #56 : agent X affiché en cellule A → A bascule sur Y → X désactivé (« visible ailleurs ») en cellule B alors que X n'est plus affiché nulle part.
|
||||
|
||||
Cause : le live registry garde X→nodeId A même après le swap ; `LayoutGrid.visibleElsewhere` lisait `live.nodeId` comme « affiché ici ».
|
||||
|
||||
Fix (frontend pur, ne tue pas la session) dans `frontend/src/features/layout/LayoutGrid.tsx` :
|
||||
- `visibleElsewhere(candidate)` dérive du **layout courant** : truthy uniquement s'il existe une feuille visible ≠ cellule courante avec `leaf.agent === candidate`. Retourne `{ nodeId }`.
|
||||
- `backgroundLive` utilise `!visibleElsewhere(candidate)` au lieu de `!visibleNodeIds.has(live.nodeId)` ; garde `live.nodeId === id` (anti-boucle self-launch).
|
||||
- onChange du select : même dérivation ; sélection inchangée (attachLiveAgent si sessionId sinon setCellAgent).
|
||||
- Prop `visibleNodeIds` supprimé (devenu mort) de tout le threading LayoutGrid→NodeView→Split/Grid/Leaf.
|
||||
|
||||
Invariant préservé : agent réellement épinglé dans une cellule visible reste NON sélectionnable ailleurs.
|
||||
|
||||
Piège de test : un test qui mocke `listLiveAgents` avec un nodeId visible mais **sans** épingler l'agent dans ce leaf ne désactive plus rien — il faut `setCellAgent` réel. Tests dans `singletonAgent.test.tsx` (describe « ticket #56 » + ajustement R0d). Suite frontend : 706 verts.
|
||||
18
.ideai/memory/ticket74-f1-web-bundle-transport-seam.md
Normal file
18
.ideai/memory/ticket74-f1-web-bundle-transport-seam.md
Normal file
@ -0,0 +1,18 @@
|
||||
---
|
||||
name: ticket74-f1-web-bundle-transport-seam
|
||||
description: Deux artefacts Vite (dist/dist-web), mode `web` portable Windows, et le câblage anti-divergence de la constante de transport.
|
||||
metadata:
|
||||
type: reference
|
||||
---
|
||||
Le frontend produit **deux** artefacts Vite depuis les mêmes sources :
|
||||
- `frontend/dist` → transport `tauri` (desktop, `build.frontendDist`) — `npm run build`.
|
||||
- `frontend/dist-web` → transport `http` (packagé en ressource Tauri `web/`) — `npm run build:web`.
|
||||
- `npm run build:bundle` produit les deux : c'est le point d'entrée du packaging Tauri.
|
||||
|
||||
**Le mode web passe par `--mode web` + `frontend/.env.web` (`VITE_TRANSPORT=http`), jamais par un préfixe inline `VITE_TRANSPORT=http vite build`** : non portable Windows/NSIS, cible active du bundle. `.env.web` est versionné (non gitignoré) ; `dist-web/` est ignoré.
|
||||
|
||||
**Anti-divergence de `__IDEA_TRANSPORT__`** : `frontend/src/app/transport.ts` expose `transportFromEnv(value)`, importé à la fois par `di.tsx` (`resolveTransport`/`shouldUseHttp`) et par `vite.config.ts`, qui lui passe `VITE_TRANSPORT` via `loadEnv(mode)`. Même variable + même prédicat = une seule source. Modifier le prédicat déplace constante et runtime ensemble. `vitest.config.ts` réplique le `define` via le même helper.
|
||||
|
||||
La constante est **publiée sur `window` dans `main.tsx`** : `define` ne remplace que les occurrences existantes et une constante non référencée serait tree-shakée ; l'affectation est un effet de bord qui survit à la minification. Elle reporte le transport hors mock (`VITE_USE_MOCK` reste un switch distinct).
|
||||
|
||||
Pour identifier le transport d'un bundle bâti : `grep -o '__IDEA_TRANSPORT__="[a-z]*"' dist*/assets/*.js`. **Ne pas se fier à la présence de `__TAURI_INTERNALS__` ni à un nom de symbole minifié** : les deux jeux d'adapters sont présents dans les deux bundles, un grep ne les discrimine pas.
|
||||
31
.ideai/memory/ticket95-adapter-aware-liveness-probe.md
Normal file
31
.ideai/memory/ticket95-adapter-aware-liveness-probe.md
Normal file
@ -0,0 +1,31 @@
|
||||
---
|
||||
name: ticket95-adapter-aware-liveness-probe
|
||||
description: memory note ticket95-adapter-aware-liveness-probe
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# #95 — Sonde de vivacité du rendez-vous devenue adapter-consciente
|
||||
|
||||
**Type :** correctif architecture / bug racine. Livré sur `feature/rendezvous-liveness-probe-per-adapter` (commit 376fc9f), AppImage 0.3.0 rebuildée.
|
||||
|
||||
## Bug racine
|
||||
Le rendez-vous `idea_ask_agent` (`run_inactivity_watchdog`, `crates/application/src/orchestrator/rendezvous.rs`) coupe en **faux `NoReply`** toute cible **structurée** dont le tour dépasse la fenêtre d'inactivité (défaut 600 s, = `turn_timeout_ms` du profil cible). Cause : la seule sonde de vivacité (`transcript_activity_token`) lisait le transcript Claude (`~/.claude/projects/<encoded-cwd>/*.jsonl`) — invisible pour OpenCode/Codex, et fragilise même Claude en mode `-p` headless si le transcript ne grossit pas mi-tour. `has_probe=true` mais la sonde renvoie `None` ⇒ bras `(true,_,None)=>false` ⇒ aucun réarmement ⇒ NoReply à la première fenêtre.
|
||||
|
||||
## Fix (architecture figée)
|
||||
1. **Port domaine** (`crates/domain/src/ports.rs`) : `AgentSession::activity_token() -> Option<u64>` (défaut `None`, zéro régression). Jeton monotone = « la session travaille ».
|
||||
2. **Machinerie** (`crates/infrastructure/src/session/process.rs`) : `run_turn_with_activity(...)` bump un `Arc<AtomicU64>` à **chaque ligne stdout lue** (drain async ET drain sandboxé thread). `run_turn` (4 args) délègue avec `None` ⇒ les ~11 call sites de test sont intacts.
|
||||
3. **Sessions** : `ClaudeSdkSession`, `CodexExecSession`, `OpenAiCompatibleSession` overrident `activity_token()` via `run_turn_with_activity` ; `OpenCodeSession` (drain inline) bump son propre compteur par ligne JSONL.
|
||||
4. **Sonde composite** (`resolve_ask_liveness_token`, `crates/backend/src/lib.rs`) : préfère `session.activity_token()` de la session vivante (`structured.session_for_agent`), repli inchangé sur le transcript Claude. Câblée par `.with_ask_liveness_probe`.
|
||||
|
||||
## Contrats clés
|
||||
- `has_probe` reste `true` dès qu'une sonde est câblée ; la sonde composite renvoie désormais `Some(token)` qui avance ⇒ la fenêtre se réarme. Le repli transcript Claude couvre le cas « session vivante sans override ».
|
||||
- La fenêtre = `turn_timeout_ms` du **profil cible** (`turn_timeout_for`→`liveness_for_agent`), défaut `ASK_AGENT_TIMEOUT` 600 s. **Pas d'env global pour la fenêtre** (seul le plafond a `IDEA_ASK_RENDEZVOUS_CEILING_MS`, défaut 4 h).
|
||||
- Pour un test live rapide sans attendre 600 s : mettre un petit `turn_timeout_ms` (ex. 20 000) sur le profil de la cible, puis déléguer une tâche de ~60-90 s.
|
||||
|
||||
## État validation
|
||||
- Tests unitaires verts : `run_turn_with_activity_bumps_counter_per_line`, `*_session_activity_token_advances_across_a_turn` (claude/codex/opencode), + la sonde composite backend + le watchdog rendezvous existants.
|
||||
- AppImage 0.3.0 rebuildée + installée (`/home/anthony/Documents/IdeA_0.3.0_amd64.AppImage`, backup `.old-pre95fix`). **Relance IdeA requise** pour l'activer (le binaire qui tourne = AppImage en mémoire ; relancer depuis l'intérieur tue la session courante).
|
||||
|
||||
## À noter (dette / hors périmètre)
|
||||
- #96 (EffectivePermissions assistants de ticket) laissé ouvert, documenté dans le carnet #96 (décision produit différée).
|
||||
- Le souvenir utilisateur initial décrivait un échec « demandeur GLM/OpenCode → cible Claude ». Mécaniquement le watchdog est **ciblé-cible** (keyed sur l'agent cible) : un échec sur cible Claude longue n'est possible que si le transcript Claude `-p` ne grossit pas mi-tour (couvert désormais par l'`activity_token` de ClaudeSdkSession). La théorie principale reste « cible structurée longue non observée → faux NoReply ».
|
||||
35
.ideai/memory/ticket97-opencode-provider-mutual-exclusion.md
Normal file
35
.ideai/memory/ticket97-opencode-provider-mutual-exclusion.md
Normal file
@ -0,0 +1,35 @@
|
||||
---
|
||||
name: ticket97-opencode-provider-mutual-exclusion
|
||||
description: memory note ticket97-opencode-provider-mutual-exclusion
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Ticket #97 — Exclusion mutuelle opencode / opencodeProvider (décision Architect)
|
||||
|
||||
## Bug
|
||||
Wizard first-run : profiles.json contient à la fois `opencode` (llamacpp) et `opencodeProvider` (cloud). Lecture priorise `opencode` → llamacpp l'emporte silencieusement.
|
||||
|
||||
## Root cause (vérifiée dans le code)
|
||||
1. `SaveOpenCodeProviderProfile::execute` (`crates/application/src/agent/usecases.rs:364-367`) pose `opencode_provider` sans faire `opencode = None`.
|
||||
2. Invariant `opencode_backend_is_consistent` (`crates/domain/src/profile.rs:1220`) existe + testé mais **jamais appelé** hors tests (garde morte).
|
||||
3. Lecture priorise `opencode` : `crates/application/src/agent/lifecycle.rs:2367` + `crates/infrastructure/src/assistant/mod.rs:252`.
|
||||
|
||||
## Décisions Architect (validées)
|
||||
- **Lot** : un seul lot cohérent. Backend = autoritaire (invariant + garde + use case via builder + migration). Frontend = strip de la config inactive au save selon le mode (requis pour les chemins SaveProfile/ConfigureProfiles qui ne portent pas d'intention explicite). Découplés/parallélisables. DevBackend + DevFrontend + QA.
|
||||
- **Frontière** :
|
||||
- Domaine : builders `with_opencode` (`profile.rs:1132`) et `with_opencode_provider` (`profile.rs:1140`) doivent imposer l'exclusion mutuelle (chacun efface l'autre). Aujourd'hui ce sont des setters muets = la faille.
|
||||
- Infrastructure : `FsProfileStore::save` rejette tout profil violant l'invariant → `AppError::Invalid` (c'est ici que le prédicat enfin s'appelle). Défense en profondeur.
|
||||
- Application : use cases utilisent les builders, jamais la mutation brute de champ.
|
||||
- Refuser l'ad-hoc `opencode = None` par use case (DRY, 4 chemins d'écriture).
|
||||
- **DTO** : garder `SaveOpenCodeProviderProfileRequestDto` (`dto.rs:1148`) whole-profile (zéro cassure frontend). Le `opencode` parasite devient inoffensif car le use case reconstruit via builder. Output = profil normalisé, autorité pour le frontend. Corriger aussi SaveProfile (`usecases.rs:269`) et ConfigureProfiles (`usecases.rs:460`).
|
||||
- **Lecture priorité** : garder `opencode` d'abord (irrelevant post-exclusion), commenter comme fallback défensif.
|
||||
- **Duplication résolution** (lifecycle.rs:2367 + assistant/mod.rs:252) : dette hexagonale préexistante, NE PAS élargir ce lot. Suivre via un futur `AgentProfile::effective_opencode_backend()` ou générateur partagé.
|
||||
- **Migration REQUISE** : profils déjà corrompus sur disque portent les deux. Recovery : à la lecture (ou passe de migration), quand les deux présents, dropper `opencode` stale (l'intention est cloud, le bug ne venant que d'une action cloud explicite). Sans cela, #97 ne corrige que les nouveaux profils.
|
||||
|
||||
## Sites de résolution (priorité) = exactement 2
|
||||
- `crates/application/src/agent/lifecycle.rs:2367`
|
||||
- `crates/infrastructure/src/assistant/mod.rs:252`
|
||||
Autres accès `.opencode` scoper en mode local, non affectés : `lifecycle.rs:2455-2468`, `model_server.rs:121-127`, `catalogue.rs:244-258`, `usecases.rs:410`.
|
||||
|
||||
## Statut
|
||||
Décision Architect posée. À faire implémenter par DevBackend (domaine builders + garde store + migration + use cases) et DevFrontend (strip au save). QA : tests domaine/store + intégration cloud + scénario migration profils corrompus.
|
||||
83
.ideai/memory/ticket98-opencode-modelsdev-cache-seed.md
Normal file
83
.ideai/memory/ticket98-opencode-modelsdev-cache-seed.md
Normal file
@ -0,0 +1,83 @@
|
||||
---
|
||||
name: ticket98-opencode-modelsdev-cache-seed
|
||||
description: memory note ticket98-opencode-modelsdev-cache-seed
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
slug: ticket98-opencode-modelsdev-cache-seed
|
||||
title: "Ticket #98 — Fix spawn OpenCode : seed du cache models.dev isolé (approche B2)"
|
||||
type: reference
|
||||
description: Cadrage figé du fix #98 (modèle écrasé par glm-5.2 au spawn pour provider catalogue cloud ex: zai) : cause racine = asymétrie picker↔spawn, approche B2 = semer best-effort le cache models.dev hôte dans le XDG_CACHE_HOME isolé.
|
||||
---
|
||||
|
||||
# Ticket #98 — Fix spawn OpenCode : seed du cache models.dev isolé
|
||||
|
||||
## Symptôme
|
||||
Wizard profil OpenCode first-run : provider catalogue cloud (ex: zai/ZAI Code) + modèle choisi → après sauvegarde l'agent tourne en `glm-5.2` quel que soit le modèle. Persistance correcte (`profiles.json` conserve `opencodeProvider.model`). `glm-5.2` est le **fallback interne d'OpenCode**, absent du code IdeA.
|
||||
|
||||
## Cause racine (confirmée + affinée par Architect)
|
||||
**Asymétrie picker↔spawn**, pas seulement « pas de bloc models » :
|
||||
|
||||
1. **Picker** (`provider_catalogue.rs:79-84,150-153`) : lit le cache models.dev via `opencode_models_cache_path()` qui résout le **vrai** cache hôte (`XDG_CACHE_HOME ?? ~/.cache`). Permet d'afficher zai + ses modèles.
|
||||
2. **Spawn** (`lifecycle.rs:2386,2400-2407` ; `assistant/mod.rs:272,277-285`) : IdeA **ré-isole** `XDG_CACHE_HOME` → `.opencode/cache` **vide** sous `run_dir`. OpenCode ne voit plus le cache.
|
||||
3. **Rendu** (`opencode_provider_config_json`, `lifecycle.rs:2795-2821` / `assistant/mod.rs:446-466`) : pour `config.custom == None` (défaut pour zai), IdeA n'émet que `apiKey` + `model: "zai/<m>"`, **sans** bloc `models`. Correct **uniquement** pour les 3 built-ins hardcodés dans le binaire OpenCode (`anthropic`, `openai`, `openrouter`).
|
||||
|
||||
→ OpenCode reçoit `model: "zai/<m>"`, ne reconnaît pas zai comme built-in, ne trouve pas le cache models.dev (isolé vide) → fallback silencieux glm-5.2.
|
||||
|
||||
- **Local/custom marchent** : émettent un bloc `models` auto-suffisant (`assistant/mod.rs:364-381`, `:447-460`).
|
||||
- **3 built-ins marchent** : hardcodés dans OpenCode.
|
||||
- Bug ne touche **que** les providers connus d'OpenCode *exclusivement via models.dev*.
|
||||
|
||||
## Approche figée : **B2 — Semer le cache models.dev isolé depuis le cache hôte**
|
||||
Après création du `XDG_CACHE_HOME` isolé, copier **best-effort** le fichier cache models.dev hôte (`opencode_models_cache_path()` → `<isolated_cache>/opencode/models.json`) via le port `FileSystem`. Lecture hôte = `std::fs` (identique au picker) ; écriture dans la home isolée.
|
||||
|
||||
**Pourquoi pas les autres :**
|
||||
- **(A)** Émettre un bloc `models`+`npm`+`baseURL` pour les catalogue → **écartée en v1** : IdeA devrait capturer le bon `npm` AI-SDK par provider depuis models.dev (`@ai-sdk/anthropic` vs `openai-compatible`…) — dupliquerait la connaissance du registry OpenCode (violation OCP), risque de régression built-ins. Gardée en **escalade** si B2 défait par refresh.
|
||||
- **(B1)** Pointer vers le vrai cache hôte (ne plus isoler) → **écartée** : casse l'isolation en écriture (pollution + race entre sessions).
|
||||
- **(C)** Bundler une copie statique models.dev dans IdeA → **écartée** : staleness + diverge picker/spawn.
|
||||
|
||||
**Auto-cohérence B2** : la précondition du bug (cache hôte présent au picker) garantit la précondition du fix (fichier à copier au spawn). Cache hôte absent → picker ne montre que les 3 built-ins → bug non atteint → fix non requis.
|
||||
|
||||
## Contrat figé
|
||||
### Ports / DTO
|
||||
- **Aucun nouveau port / entité domaine / DTO modifié.** Réutilise le port `FileSystem` déjà injecté sur le chemin spawn. Lecture source = `std::fs` hôte (mécanisme identique au picker).
|
||||
- Rendre **publique** `opencode_models_cache_path()` (source de vérité unique — encode le workaround du bug upstream #8235 ; ne **pas** re-dériver).
|
||||
|
||||
### Fichiers (périmètre DevBackend)
|
||||
- `crates/application/src/agent/provider_catalogue.rs` — exposer `opencode_models_cache_path()` en `pub` (ou ajouter `pub fn read_models_dev_cache_bytes() -> Option<Vec<u8>>`).
|
||||
- `crates/application/src/agent/mod.rs` — re-export.
|
||||
- `crates/application/src/agent/lifecycle.rs` — branche `apply_mcp_config` (≈2382-2408) : après `create_dir_all` du cache + création `xdg_cache`, semer `<xdg_cache>/opencode/models.json` depuis le cache hôte, best-effort. Branche **commune** opencode + opencodeProvider.
|
||||
- `crates/infrastructure/src/assistant/mod.rs` — branche miroir (≈268-285) : même appel.
|
||||
- **Factoriser** : `application::agent::seed_opencode_models_cache(fs: &dyn FileSystem, isolated_cache_dir: &str)` appelée par les deux sites. Partie **pure** testable `seed_from_bytes(fs, dest, src_bytes)` ; wrapper impur `std::fs::read` fin.
|
||||
|
||||
### Invariants (stricts)
|
||||
1. Isolation préservée en **écriture** : HOME, XDG_CONFIG_HOME, XDG_DATA_HOME, XDG_CACHE_HOME restent sous `run_dir`. Aucune var d'env repointée vers l'hôte. Seul le **contenu** du cache isolé est semé (lecture seule).
|
||||
2. **Best-effort, n'échoue jamais le launch** : source absente/illisible ou erreur FS → pas d'échec du spawn. Symétrique du contrat best-effort existant de `apply_mcp_config` (`lifecycle.rs:2422-2425`). ≠ `resolve_opencode_provider_api_key` (échec dur). Le seed est **mou**.
|
||||
3. Pas de régression local/custom : `opencode_config_json` (llamacpp) et `opencode_provider_config_json(custom==Some)` **byte-identiques** (rendu non touché ; seed additif orthogonal).
|
||||
4. Pas de régression built-ins : anthropic/openai/openrouter (`custom==None`, hardcodés) restent fonctionnels.
|
||||
5. Exclusion mutuelle `opencode` vs `opencodeProvider` (#97) : non touchée.
|
||||
6. Source de vérité unique du chemin models.dev : `opencode_models_cache_path()` réutilisée.
|
||||
7. Cohérence picker↔spawn : modèles résolvables au spawn = sur-ensemble de ceux du picker (même fichier source).
|
||||
|
||||
### Hors périmètre (ne pas faire ici)
|
||||
- Résolution providers pour **projets remote (SSH/WSL)** (picker lit déjà le cache hôte — incohérence pré-existante). Fix corrige le cas **local**, ne régresse pas le remote.
|
||||
- Déduplication du rendu lifecycle↔infra (`opencode_provider_config_json` ×2) — on factorise **uniquement le seeder**.
|
||||
- Aucune modif UI/wizard.
|
||||
|
||||
## QA — 2 couches
|
||||
1. **Unitaire `application`** (automatisable, déterministe) :
|
||||
- Partie pure `seed_from_bytes(fs, dest, src_bytes)` : bytes présents → assert `<dest>/opencode/models.json` écrit identique ; `None` → aucun fichier **et** pas d'erreur.
|
||||
- Non-régression rendu : JSON de `opencode_config_json` et `opencode_provider_config_json(custom==Some/None)` byte-identiques (tests existants `lifecycle.rs:4428+` verts).
|
||||
- ⇒ Ne prouve **pas** la résolution réelle par OpenCode.
|
||||
2. **Intégration / réelle-exécution (gated, propriété QA)** : spawn réel d'OpenCode avec profil `zai` (`custom==None`) contre un cache models.dev fixture contenant `zai` ; assert **pas de fallback glm-5.2** (modèle `zai/<choix>` effectivement utilisé). Gater `#[ignore]`/env (clé API + réseau). **C'est ce test qui prouve le bug corrigé.**
|
||||
|
||||
## Risque résiduel + escalade
|
||||
- **Inconnu empirique** : est-ce qu'OpenCode au démarrage tente de **rafraîchir** models.dev (écrase notre copie, ou hang sans réseau) ? `OPENCODE_DISABLE_AUTOUPDATE=1` ne vise que l'auto-update du binaire, pas sûr qu'il couvre le refresh models. **QA doit vérifier** sur le test d'intégration. Si le refresh défait B2 → **escalader vers (A)** : capturer `npm`+`baseURL` réels par provider dans le parseur models.dev et peupler `custom`.
|
||||
|
||||
## Topologie
|
||||
- Branche : `feature/ticket98-opencode-modelsdev-cache-seed` depuis `develop@69e5878` (#97 exclusion mutuelle prérequis y est fusionné : `0f0a76d` + merge `5533073`). `crates/` propre.
|
||||
- Carnet #98 version 2 = source de vérité du cadrage.
|
||||
|
||||
## Lié
|
||||
- #97 (relatesTo) : exclusion mutuelle provider — prérequis livré.
|
||||
51
.ideai/memory/tickets-70-100-102-ux-surface-scoping.md
Normal file
51
.ideai/memory/tickets-70-100-102-ux-surface-scoping.md
Normal file
@ -0,0 +1,51 @@
|
||||
---
|
||||
name: tickets-70-100-102-ux-surface-scoping
|
||||
description: memory note tickets-70-100-102-ux-surface-scoping
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
title: Cadrage UX tickets #70 #100 #102 — modèles locaux et bugs terminal
|
||||
type: design
|
||||
description: Surface utilisateur attendue pour supprimer les modèles llama.cpp téléchargés, et règle UX pour les bugs de scroll/fit OpenCode qui doivent être corrigés sans nouvelle UI.
|
||||
---
|
||||
|
||||
# Cadrage UX tickets #70 #100 #102
|
||||
|
||||
## #70 — Gestion des modèles locaux téléchargés
|
||||
|
||||
Ajouter une affordance humaine de suppression des artefacts de modèles téléchargés par les serveurs locaux llama.cpp, dans la surface existante `Local model servers` / configuration OpenCode locale.
|
||||
|
||||
Principes visibles :
|
||||
- La suppression d'un serveur déclaré et la suppression du fichier modèle téléchargé sont deux actions distinctes.
|
||||
- Une action destructive sur le fichier modèle doit être explicite, confirmée, et impossible pendant un usage actif/téléchargement du même artefact.
|
||||
- Le libellé doit parler de `modèle téléchargé`, pas de cache interne ou chemin technique en premier niveau.
|
||||
- Les modèles issus d'un `localPath` utilisateur ne doivent jamais être proposés à la suppression comme s'ils appartenaient à IdeA.
|
||||
|
||||
États attendus par serveur :
|
||||
- Aucun modèle téléchargé connu : aucun bouton de suppression de modèle, ou bouton désactivé avec tooltip `Aucun modèle téléchargé par IdeA`.
|
||||
- Modèle téléchargé disponible : bouton secondaire/destructif `Supprimer le modèle téléchargé`.
|
||||
- Téléchargement/préparation en cours : action désactivée, texte `Téléchargement en cours`.
|
||||
- Serveur/agent utilisant ce modèle : action désactivée, texte `Modèle utilisé par un agent en cours`.
|
||||
- Suppression en cours : ligne locale occupée, action désactivée, message `Suppression du modèle...`.
|
||||
- Succès : toast/status non bloquant `Modèle téléchargé supprimé` ; la configuration serveur reste présente.
|
||||
- Échec : alerte inline `Impossible de supprimer le modèle téléchargé : <raison courte>`.
|
||||
|
||||
Confirmation :
|
||||
- Titre : `Supprimer le modèle téléchargé ?`
|
||||
- Corps : `Le serveur local restera configuré, mais IdeA devra retélécharger ce modèle au prochain lancement.`
|
||||
- Si la taille est connue : ajouter `Espace libéré : <taille>.`
|
||||
- Action principale destructive : `Supprimer le modèle`
|
||||
- Action secondaire : `Annuler`
|
||||
|
||||
## #100 — Scroll OpenCode
|
||||
|
||||
Pas de décision UX spécifique. Le comportement attendu est celui d'une cellule terminal native : l'utilisateur peut remonter dans le scrollback OpenCode jusqu'à la limite de rétention disponible, avec molette, trackpad, scrollbar et clavier, sans blocage prématuré propre à OpenCode.
|
||||
|
||||
Ne pas ajouter de bouton, message ou mode spécial OpenCode. QA doit valider le comportement visible dans une cellule OpenCode longue.
|
||||
|
||||
## #102 — Fit TUI après switch/layout/ajout cellule
|
||||
|
||||
Pas de nouvelle surface UX spécifique. Le terminal doit s'afficher correctement automatiquement après switch de projet, switch de layout, ajout/suppression/split/resize de cellules et rattachement d'une session existante.
|
||||
|
||||
Ne pas afficher de message demandant à l'utilisateur de redimensionner. Éviter tout flash durable vide/noir ; un voile technique transitoire n'est acceptable que s'il reste très bref et non bloquant.
|
||||
53
.ideai/memory/toolchain-rust-partage-acces-agents.md
Normal file
53
.ideai/memory/toolchain-rust-partage-acces-agents.md
Normal file
@ -0,0 +1,53 @@
|
||||
---
|
||||
name: toolchain-rust-partage-acces-agents
|
||||
description: memory note toolchain-rust-partage-acces-agents
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
slug: toolchain-rust-partage-acces-agents
|
||||
title: Accès au toolchain Rust/Tauri partagé pour tous les agents (isolement HOME OpenCode)
|
||||
type: project
|
||||
description: Le toolchain Rust stable est déjà installé sur la machine mais invisible aux agents car le profil OpenCode isole HOME. Diagnostic, atténuation par symlink, et chantier durable (injection env au spawn).
|
||||
---
|
||||
|
||||
# Toolchain Rust/Tauri : pourquoi les agents ne compilaient pas, et comment les débloquer
|
||||
|
||||
## Symptôme (récurrent)
|
||||
Tout agent (Main, DevBackend, QA,…) lancé sous un profil OpenCode ne peut PAS compiler le workspace Rust/Tauri :
|
||||
- `cargo`/`rustc` = shims rustup qui répondent « no default toolchain » / « no installed toolchains ».
|
||||
- Bloque toute validation backend (cargo check/build/test), fait timeout les délégations lourdes.
|
||||
|
||||
## Cause racine
|
||||
- Le toolchain **stable 1.94.1 est DÉJÀ installé** dans `/home/anthony/.rustup` + `/home/anthony/.cargo` (toolchains + bin).
|
||||
- MAIS le profil **OpenCode isole `HOME`** vers `.ideai/run/<agent_uuid>/.opencode/`. Donc `~/.rustup` et `~/.cargo` = `.opencode/.rustup` / `.opencode/.cargo`, qui ne contiennent qu'un `settings.toml` + un cache registry partiel → **aucun toolchain**.
|
||||
- IdeA lui-même ne set **ni** `RUSTUP_HOME` **ni** `CARGO_HOME` (grep vide dans `crates/`). Le point d'extension existe pourtant : `crates/infrastructure/src/session/opencode.rs:237` (`cmd.env(key, value)`) set déjà des env au spawn.
|
||||
- `target/` est dans le project root (partagé, géré par le lock cargo) → partageable sans conflit.
|
||||
- `tauri` est dispo via `frontend/node_modules/.bin/tauri` (après `npm install` du frontend).
|
||||
|
||||
## Atténuation appliquée (2026-07-25, ops, sans rebuild)
|
||||
Symlinker les homes isolés vers les homes partagés pour chaque run-dir agent :
|
||||
```bash
|
||||
for d in .ideai/run/*/.opencode; do
|
||||
for sub in .rustup .cargo; do
|
||||
p="$d/$sub"
|
||||
[ -e "$p" ] && [ ! -L "$p" ] && { rm -rf "$p"; ln -s "/home/anthony/$sub" "$p"; }
|
||||
done
|
||||
done
|
||||
```
|
||||
Vérifié sur Main : `cargo 1.94.1` / `rustc 1.94.1` accessibles **sans aucune variable d'env explicite**. Symlink appliqué aux agents actifs (Main a6ced819, DevBackend 73c853d1, QA aefdbd61, …) — 5 run-dirs concernés.
|
||||
|
||||
**Tient pour les agents existants** : rustup suit les symlinks, et OpenCode ne recrée pas `$HOME/.rustup` s'il existe déjà.
|
||||
|
||||
## Solution DURABLE (chantier IdeA, à livrer)
|
||||
Pour les **nouveaux** agents (IdeA crée un nouveau run-dir `.ideai/run/<uuid>/.opencode/.rustup` vide), il faut qu'IdeA provisionne l'accès au toolchain partagé automatiquement. Deux options équivalentes, à faire par DevBackend + **rebuild AppImage + relance** :
|
||||
1. Au spawn de l'agent, injecter `RUSTUP_HOME=/home/anthony/.rustup` et `CARGO_HOME=/home/anthony/.cargo` (point d'extension `opencode.rs:237`). Valeurs résolues depuis le vrai HOME user (pas le HOME isolé), idéalement configurables (env projet / settings).
|
||||
2. Ou, à la création du run-dir, créer les deux symlinks `.opencode/.rustup` et `.opencode/.cargo` → homes partagés.
|
||||
|
||||
Recommandation : option 1 (injection env) — moteur-agnostique (marche aussi pour Codex/Claude si un jour ils isolent aussi) et ne dépend pas du filesystem layout du moteur.
|
||||
|
||||
À grouper dans le **même rebuild AppImage** que le fix « sonde de vivacité multi-moteur » (cf. `idea-memory` à venir) — les deux sont des chantiers runtime qui nécessitent rebuild + relance.
|
||||
|
||||
## Liens
|
||||
- Règle rebuild AppImage : `.ideai/skills/md/a72dac60-641c-4417-b0d7-94b8539f817a.md` (skill build AppImage), mémoire `mcp-bridge-and-delegation-runtime-notes`.
|
||||
- Timeout délégation 600 s (autre symptôme sur les tâches lourdes) : mémoire `rendezvous-600s-cap-too-short-heavy-tasks` + sonde Claude-seule `crates/infrastructure/src/inspector/claude_paths.rs:89`.
|
||||
@ -0,0 +1,41 @@
|
||||
---
|
||||
name: ux-ai-profiles-opencode-persistence-list-coherence
|
||||
description: memory note ux-ai-profiles-opencode-persistence-list-coherence
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
---
|
||||
title: UX — Cohérence profils IA/OpenCode entre éditeur et picker agents
|
||||
type: decision
|
||||
description: Décisions de surface pour corriger la création de profils OpenCode, la persistance visible après sauvegarde et la cohérence entre Settings > Profils IA et les sélecteurs d'agents.
|
||||
---
|
||||
|
||||
# UX — Profils IA/OpenCode : création, persistance, liste unique
|
||||
|
||||
## Décision centrale
|
||||
La liste visible dans `Settings > Profils IA` et les pickers de profils des agents doit représenter la même collection persistée de profils IA. Les profils de référence ne sont qu'une source d'ajout, pas une deuxième vérité visible.
|
||||
|
||||
## Comportement attendu
|
||||
- Le bouton de création OpenCode s'appelle `Créer un profil OpenCode` dans la surface française.
|
||||
- Cliquer sur ce bouton ajoute immédiatement une ligne de profil en brouillon, sélectionnée, éditable et clairement marquée non enregistrée tant que la sauvegarde n'a pas réussi.
|
||||
- Chaque nouveau profil OpenCode doit avoir une identité distincte et un nom humain distinct par défaut, par exemple `OpenCode local 2`; l'utilisateur peut renommer avant sauvegarde.
|
||||
- `Dupliquer` conserve la configuration du profil source mais crée une nouvelle identité et un nom suffixé, par exemple `(copie)`.
|
||||
- `Enregistrer` persiste tous les profils sélectionnés/édités, puis recharge la liste depuis la source persistée. La liste affichée après succès doit être le résultat relu, pas seulement l'état local optimiste.
|
||||
- Après sauvegarde réussie, le profil créé reste visible dans l'éditeur sans réouverture manuelle et apparaît dans le picker de création d'agent et dans le picker de changement de profil d'un agent existant.
|
||||
- Les profils OpenCode ne doivent jamais être fusionnés/dédupliqués par commande, modèle, endpoint ou adapter. La déduplication visible se fait uniquement par `id`.
|
||||
- En mode édition, les profils déjà configurés apparaissent en premier, pré-sélectionnés, avec leur configuration réelle intacte. Les profils de référence non configurés peuvent suivre comme suggestions non sélectionnées.
|
||||
- Si un profil référencé par un agent n'existe plus dans la liste persistée, le picker de l'agent conserve l'id courant comme option orpheline lisible, sans le mélanger aux profils disponibles.
|
||||
|
||||
## États et feedback
|
||||
- Pendant la création/clonage : bouton désactivé ou loading local, sans bloquer la détection CLI.
|
||||
- Ligne brouillon : indicateur discret `Non enregistré` ou état visuel équivalent.
|
||||
- Sauvegarde réussie : statut court `Profils enregistrés` puis disparition automatique.
|
||||
- Échec sauvegarde : message d'erreur persistant, la ligne brouillon reste éditable et n'est pas perdue.
|
||||
- Picker agents vide : ne pas encourager la saisie libre d'id comme chemin normal. Afficher plutôt un état vide actionnable vers `Profils IA`.
|
||||
|
||||
## Critères d'acceptation visuels
|
||||
- Créer un profil OpenCode, sauvegarder, rester sur Settings : le profil est toujours visible après le retour succès.
|
||||
- Sans fermer Settings, ouvrir/créer un agent : le même profil est disponible dans le picker.
|
||||
- Deux profils OpenCode avec même endpoint/modèle mais ids distincts restent deux lignes et deux options distinctes.
|
||||
- Renommer un profil puis sauvegarder met à jour le libellé dans l'éditeur et dans les pickers agents.
|
||||
- Aucun écran ne montre simultanément une liste issue seulement des références et une liste issue des profils persistés comme si elles étaient équivalentes.
|
||||
@ -0,0 +1,44 @@
|
||||
---
|
||||
name: web-client-is-single-column-no-desktop-shell
|
||||
description: memory note web-client-is-single-column-no-desktop-shell
|
||||
metadata:
|
||||
type: project
|
||||
---
|
||||
# Le client web n'a pas de shell desktop (ni docks, ni layout grid)
|
||||
|
||||
Constat établi en livrant le ticket #69 (adaptibilité téléphone), sur `develop @ 506d589`.
|
||||
|
||||
## Le fait
|
||||
|
||||
Le client web livré par #13 (`VITE_TRANSPORT=http`) **n'a jamais eu** de docks
|
||||
gauche/droite, de fenêtres flottantes, de `LayoutTree`, de tabs projet, de menus ni
|
||||
de toasts. `main.tsx` route `isWeb` vers `WebApp`, qui est une surface autonome :
|
||||
|
||||
- `WebApp` → `PairingScreen` **ou** `WebWorkspace` (rien d'autre) ;
|
||||
- `WebWorkspace` → une **colonne verticale unique** (`flex flex-col overflow-y-auto`) ;
|
||||
- `WebAgentCell` → `TerminalView`.
|
||||
|
||||
Les seuls imports `@/features/*` de tout `features/web/` sont `terminals` et
|
||||
`workstate/useProjectWorkState`. Le shell desktop (`App`, layout, docks) n'est
|
||||
atteignable que par la branche non-web de `main.tsx`.
|
||||
|
||||
## Pourquoi ça compte
|
||||
|
||||
Le cadrage de #69 prévoyait un lot « remplacer les docks gauche/droite/floating par
|
||||
une pile verticale, drawer ou bottom sheet ». Ce lot était **sans objet** : il n'y a
|
||||
pas de dock à remplacer, et l'arbitrage produit « bottom sheet vs drawer » ne se pose
|
||||
pas sur cette surface. Le vrai travail téléphone était ailleurs (terminal xterm
|
||||
pilotable au doigt, `dvh`, safe-area, rangées qui débordent à 360px).
|
||||
|
||||
**Avant de cadrer un ticket « responsive / mobile » sur le client web, partir de
|
||||
`features/web/`, pas du shell desktop.** Les deux surfaces ne partagent que
|
||||
`TerminalView` et les hooks transport-neutres.
|
||||
|
||||
## Garde en place
|
||||
|
||||
`frontend/src/features/web/WebMobile.test.tsx` épingle la frontière : le client web
|
||||
ne doit monter aucun `layout-grid` / `layout-grid-container` / `layout-split` /
|
||||
`layout-tabs`. Si un jour on veut du desktop-shell dans le web, ce test tombe — et
|
||||
c'est le signal qu'il faut re-cadrer, pas le supprimer.
|
||||
|
||||
Voir aussi [[ui-rework-sprint-scoping-contracts]].
|
||||
@ -187,6 +187,44 @@
|
||||
],
|
||||
"fallback": "allow"
|
||||
}
|
||||
},
|
||||
{
|
||||
"agentId": "5d07e4a7-8676-4a71-aea1-5b64caefa944",
|
||||
"permissions": {
|
||||
"rules": [
|
||||
{
|
||||
"capability": "read",
|
||||
"effect": "allow",
|
||||
"paths": [
|
||||
"**"
|
||||
],
|
||||
"commands": []
|
||||
},
|
||||
{
|
||||
"capability": "write",
|
||||
"effect": "deny",
|
||||
"paths": [
|
||||
"**"
|
||||
],
|
||||
"commands": []
|
||||
},
|
||||
{
|
||||
"capability": "delete",
|
||||
"effect": "deny",
|
||||
"paths": [
|
||||
"**"
|
||||
],
|
||||
"commands": []
|
||||
},
|
||||
{
|
||||
"capability": "executeBash",
|
||||
"effect": "allow",
|
||||
"paths": [],
|
||||
"commands": []
|
||||
}
|
||||
],
|
||||
"fallback": "allow"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
111
.ideai/skills/md/eb76ce50-c05c-443b-8ba5-36bda091a148.md
Normal file
111
.ideai/skills/md/eb76ce50-c05c-443b-8ba5-36bda091a148.md
Normal file
@ -0,0 +1,111 @@
|
||||
# Build de l'AppImage IdeA (Linux)
|
||||
|
||||
Procédure canonique pour reconstruire l'AppImage Linux d'IdeA et les bundles frontend associés.
|
||||
|
||||
À utiliser à chaque fois qu'un correctif doit être visible dans l'app desktop. Rappel produit : **le binaire qui tourne = l'AppImage installée, pas les sources**. Un correctif source n'est actif dans l'app desktop qu'après rebuild, remplacement de l'AppImage utilisée, puis relance d'IdeA.
|
||||
|
||||
## Commande principale
|
||||
|
||||
Depuis le project root `/home/anthony/Documents/Projects/IdeA` :
|
||||
|
||||
```bash
|
||||
cd crates/app-tauri
|
||||
APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=true ../../frontend/node_modules/.bin/tauri build --bundles appimage
|
||||
```
|
||||
|
||||
Cette commande déclenche `build.beforeBuildCommand`, donc elle reconstruit automatiquement les deux bundles frontend :
|
||||
|
||||
- `frontend/dist` : bundle desktop, transport `tauri`.
|
||||
- `frontend/dist-web` : bundle web, transport `http`.
|
||||
|
||||
Ne pas revenir à l'ancienne procédure `npm --prefix frontend run build` seule : elle ne reconstruit pas le bundle web séparé.
|
||||
|
||||
## Vérification des bundles web/desktop
|
||||
|
||||
Après le build, lancer :
|
||||
|
||||
```bash
|
||||
npm --prefix frontend run test:bundle-transport
|
||||
```
|
||||
|
||||
Sortie attendue :
|
||||
|
||||
```text
|
||||
dist: __IDEA_TRANSPORT__="tauri" (1 marker)
|
||||
dist-web: __IDEA_TRANSPORT__="http" (1 marker)
|
||||
```
|
||||
|
||||
## Artefact attendu
|
||||
|
||||
```text
|
||||
target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
|
||||
```
|
||||
|
||||
Vérifier rapidement :
|
||||
|
||||
```bash
|
||||
ls -lh target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
|
||||
APPIMAGE_EXTRACT_AND_RUN=1 target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage --appimage-help | head
|
||||
```
|
||||
|
||||
## Pourquoi ces variables sont obligatoires
|
||||
|
||||
- `--bundles appimage` : cible uniquement l'AppImage Linux et évite les bundles inutiles/cassants comme NSIS.
|
||||
- `NO_STRIP=true` : évite l'échec linuxdeploy/strip sur les bibliothèques système modernes contenant `.relr.dyn`.
|
||||
- `APPIMAGE_EXTRACT_AND_RUN=1` : évite l'échec FUSE quand linuxdeploy ou appimagetool ne peuvent pas monter une AppImage dans l'environnement courant.
|
||||
|
||||
## Fallback si Tauri échoue à `failed to run linuxdeploy`
|
||||
|
||||
Symptôme : la commande Tauri reconstruit `frontend/dist`, `frontend/dist-web`, compile `target/release/app-tauri`, crée `target/release/bundle/appimage/IdeA.AppDir`, puis échoue seulement à l'étape finale :
|
||||
|
||||
```text
|
||||
failed to bundle project `failed to run linuxdeploy`
|
||||
```
|
||||
|
||||
Ne pas réanalyser tout le build. Faire ce diagnostic court :
|
||||
|
||||
```bash
|
||||
APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=true LDAI_OUTPUT=/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage \
|
||||
/home/anthony/.cache/tauri/linuxdeploy-x86_64.AppImage \
|
||||
--appdir /home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA.AppDir \
|
||||
--output appimage
|
||||
```
|
||||
|
||||
Si `appimagetool` échoue avec téléchargement runtime impossible :
|
||||
|
||||
```text
|
||||
Failed to download runtime file
|
||||
```
|
||||
|
||||
utiliser le runtime local déjà en cache et l'`appimagetool` extrait. Chercher le dossier extrait récent :
|
||||
|
||||
```bash
|
||||
find /tmp -path '*/appimagetool-prefix/usr/bin/appimagetool' -type f -printf '%p\n' | tail -1
|
||||
```
|
||||
|
||||
Puis lancer en remplaçant `<EXTRACTED>` par le préfixe trouvé, par exemple `/tmp/appimage_extracted_xxx` :
|
||||
|
||||
```bash
|
||||
PATH=<EXTRACTED>/appimagetool-prefix/usr/bin:$PATH \
|
||||
ARCH=x86_64 \
|
||||
<EXTRACTED>/appimagetool-prefix/usr/bin/appimagetool \
|
||||
--runtime-file /home/anthony/.cache/tauri/runtime-x86_64 \
|
||||
/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA.AppDir \
|
||||
/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
|
||||
```
|
||||
|
||||
Le `PATH` est nécessaire parce que `mksquashfs` est fourni dans `appimagetool-prefix/usr/bin` et peut être absent du PATH système.
|
||||
|
||||
## Relance de l'application
|
||||
|
||||
Ne pas relancer IdeA automatiquement depuis une session active : cela tue l'orchestrateur courant et les ponts MCP. Une fois l'AppImage reconstruite, l'utilisateur décide quand remplacer/lancer l'artefact final.
|
||||
|
||||
## Piège d'environnement AppImage
|
||||
|
||||
Une session shell lancée depuis l'AppImage peut hériter de variables comme `APPDIR`, `LD_LIBRARY_PATH`, `PYTHONHOME` pointant vers `/tmp/.mount_IdeA_*`. Symptômes possibles : `python3` casse avec `No module named 'encodings'`, ou un binaire Tauri local se lance dans un environnement pollué.
|
||||
|
||||
Pour des commandes sensibles, préférer un environnement propre ou éviter Python :
|
||||
|
||||
```bash
|
||||
env -i PATH=/usr/bin:/bin HOME=$HOME XDG_RUNTIME_DIR=/run/user/1000 <commande>
|
||||
```
|
||||
@ -0,0 +1,11 @@
|
||||
---
|
||||
id: "e28a4d53-8bd2-446a-b0ac-2a017373b8b2"
|
||||
order: 5
|
||||
name: "Gestion des bugs"
|
||||
status: "planned"
|
||||
createdBy: {"kind":"user"}
|
||||
updatedBy: {"kind":"user"}
|
||||
createdAt: 1783923775150
|
||||
updatedAt: 1783923775150
|
||||
version: 1
|
||||
---
|
||||
@ -36,6 +36,15 @@
|
||||
"status": "planned",
|
||||
"updatedAt": 1783757205620,
|
||||
"version": 2
|
||||
},
|
||||
{
|
||||
"id": "e28a4d53-8bd2-446a-b0ac-2a017373b8b2",
|
||||
"path": "e28a4d53-8bd2-446a-b0ac-2a017373b8b2",
|
||||
"order": 5,
|
||||
"name": "Gestion des bugs",
|
||||
"status": "planned",
|
||||
"updatedAt": 1783923775150,
|
||||
"version": 1
|
||||
}
|
||||
]
|
||||
}
|
||||
6
.ideai/system-permissions.json
Normal file
6
.ideai/system-permissions.json
Normal file
@ -0,0 +1,6 @@
|
||||
{
|
||||
"version": 1,
|
||||
"projectDefault": {
|
||||
"network": "allow"
|
||||
}
|
||||
}
|
||||
@ -1,29 +0,0 @@
|
||||
---
|
||||
issueRef: "#1"
|
||||
version: 11
|
||||
updatedBy: {"kind":"user"}
|
||||
updatedAt: 1783175265022
|
||||
---
|
||||
- Cadrage: background-tasks-first-class-design. Arbitrage 5 écarts: b8-arbitration-outcomes.
|
||||
- FAIT B8 runner PTY + boucle sink fermée + refactor point-2. QA vert. Commit backend 8cac147.
|
||||
- FAIT UI cancel/retry câblés (cancel_background_task/retry_background_task). Commit frontend c179f93.
|
||||
- FAIT déclencheur in-app: surface MCP idea_run_in_background (BE-1+BE-2), commit f08dae6. Ferme l'écart de périmètre « aucun producteur ».
|
||||
- Dette tracée: #2 (PtyPort::wait + tee live), #3 (persistance sûre invocation/retry-after-reboot + énumération store), #5 (contrat DTO work-state).
|
||||
|
||||
## MAJ 2026-07-04 — part autonome de #1 clôturée (Main)
|
||||
- AppImage rebuild frais confirmé (build 2026-07-03 23:56 > dernier source 23:53), inclut T1+T3, NO_STRIP=true.
|
||||
- VALIDATION AUTOMATISÉE VERTE : cargo build --workspace OK ; cargo test -p application / -p app-tauri / -p infrastructure = 0 failed ; frontend npm run build OK + vitest 459/460. L'unique rouge = flake de timing src/features/permissions/permissions.test.tsx (passe en isolation 2/2, non touché par #1, pas une régression).
|
||||
- COMMITS Git sur feature/background-tasks-first-class : eb9cc16 (code T1+T3, 21 fichiers) + ebd992e (19 notes mémoire + MEMORY.md). AUCUN merge vers develop. Runtime .ideai/{background-tasks,proposals,tickets}/ volontairement non commités.
|
||||
|
||||
## ⚠️ MAJ 2026-07-04 — IMPACT TOPOLOGIE (constat Git, cadrage #4)
|
||||
- `feature/background-tasks-first-class` (#1) est DÉRIVÉE du `develop` ANORMAL/rembobiné (merge-base #1↔main = 1fc7869, pré-canonique ; a9653bc tip develop est ancêtre de #1). Donc #1 = baseline PRÉ-CANONIQUE (spawn_turn=0, run_turn batch, pas d'AgentTurnEvent).
|
||||
- La vraie ligne d'intégration est `main` (canonique, release ~01/07), PAS le develop rembobiné (18 commits en retard sur main). ⇒ la cible de merge « → develop » prévue au point 3 ci-dessous est INVALIDÉE.
|
||||
- #1 modifie massivement les fichiers divergés côté canonique : orchestrator/service.rs +425, domain/events.rs +184, lifecycle.rs +83, session/codex.rs. ⇒ portage sur canonique = CONFLITS NON TRIVIAUX attendus, pas un simple changement de cible.
|
||||
- PLAN Git (Phase C, à faire quand on reprendra #1) : branche fraîche `feature/background-tasks-first-class-canonical` depuis main + cherry-pick séquentiel des 17 commits (ancienne branche gardée comme filet), conflits sémantiques service/events escaladés à DevBackend/Architect, puis QA avant tout merge.
|
||||
- Décision de reconstruction de `develop` sur `main` : DESTRUCTIVE (rewrite branche partagée) → en attente validation utilisateur.
|
||||
|
||||
## RESTE — DÉPENDANT UTILISATEUR (Main ne peut pas seul)
|
||||
1. Re-QA LIVE T3 : relancer l'AppImage fraîche puis vérifier onglet Work → Cancel/Retry (T3-a..f du cadrage workstate-background-tasks-projection-fix). QA non pilotable depuis sandbox → besoin app lancée.
|
||||
2. T2 — reconcile après reboot (fin AVANT wake), protocole MANUEL, coordination reboot utilisateur.
|
||||
3. [CIBLE À REVOIR] merge de #1 : ne plus viser le develop rembobiné. Porter #1 sur canonique (Phase C ci-dessus) PUIS merger vers develop-reconstruit/main. Dépend de la décision de reconstruction de develop.
|
||||
Main travaille sur #4 (annonces inter-agent) en attendant la dispo utilisateur pour 1-2-3.
|
||||
@ -1,24 +0,0 @@
|
||||
---
|
||||
id: "ec19c041-7a44-456d-994d-f0dcb7c52f39"
|
||||
number: 1
|
||||
title: "Tâches de fond — finaliser B8 (runner PTY) et clôturer le chantier"
|
||||
status: "closed"
|
||||
priority: "medium"
|
||||
links: []
|
||||
agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
|
||||
createdBy: {"kind":"user"}
|
||||
updatedBy: {"kind":"user"}
|
||||
createdAt: 1783026129089
|
||||
updatedAt: 1783175265022
|
||||
version: 11
|
||||
---
|
||||
Description :
|
||||
|
||||
Le chantier « tâches de fond de 1re classe » est livré et QA-vert jusqu'à B7 inclus (mailbox bornée, rendez-vous inter-agent comme tâche durable, reconcile au boot, réveil du propriétaire, UI F1–F4). Commité sur feature/background-tasks-first-class (e05edc6 backend, 5d88c95 frontend), non mergé. Reste à fermer les points suivants avant de considérer le chantier terminé.
|
||||
|
||||
Reste à faire :
|
||||
|
||||
- [ ] B8 — runner de commandes couplé PTY : créer un BackgroundTask{kind: Command} au spawn d'une commande longue (côté pty.rs / LocalProcessSpawner) et pousser exit/stdout/stderr dans le completion sink. C'est ce qui active le flux run_in_background complet : une commande qui finit après la fin du tour de l'agent réveille automatiquement son propriétaire avec le résultat. Aujourd'hui le sink est prêt mais aucun runner concret ne s'y abonne.
|
||||
- [ ] UI cancel / retry des tâches de fond : les boutons existent mais sont désactivés faute de commande Tauri. Exposer cancel/retry (dépend de B8) et brancher l'UI.
|
||||
- [ ] Validation live end-to-end de la feature dans l'app réelle : lancer un build/commande longue en run_in_background, laisser le tour se terminer, vérifier que le propriétaire est bien re-réveillé avec le résultat (et idem après redémarrage d'IdeA entre la fin et le wake — le reconcile doit retrouver la complétion).
|
||||
- [ ] Merge feature/background-tasks-first-class → develop (sur validation) : résorbe aussi les 4 tests de protocole MCP périmés qui sont encore rouges sur develop (le fix d'alignement vit sur cette branche).
|
||||
@ -1,6 +0,0 @@
|
||||
---
|
||||
issueRef: "#10"
|
||||
version: 5
|
||||
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
||||
updatedAt: 1783241883970
|
||||
---
|
||||
@ -1,15 +0,0 @@
|
||||
---
|
||||
id: "37bfbb89-a8a5-475f-91bf-ecfd60ee4203"
|
||||
number: 10
|
||||
title: "Ticket par sprint"
|
||||
status: "closed"
|
||||
priority: "medium"
|
||||
links: []
|
||||
agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
|
||||
createdBy: {"kind":"user"}
|
||||
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
||||
createdAt: 1783183841014
|
||||
updatedAt: 1783241883970
|
||||
version: 5
|
||||
---
|
||||
J'aimerais pouvoir regrouper mes tickets en sprints. C'est a dire en catégories qui auraient elles meme un ordre d'execution (sprint 1, sprint 2 etc)
|
||||
@ -1,6 +0,0 @@
|
||||
---
|
||||
issueRef: "#11"
|
||||
version: 6
|
||||
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
||||
updatedAt: 1783278726067
|
||||
---
|
||||
@ -1,15 +0,0 @@
|
||||
---
|
||||
id: "dad53cb9-a818-4475-be12-fd3ba6c59638"
|
||||
number: 11
|
||||
title: "Interface de création de sprint"
|
||||
status: "closed"
|
||||
priority: "medium"
|
||||
links: [{"target":"#10","kind":"dependsOn"}]
|
||||
agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
|
||||
createdBy: {"kind":"user"}
|
||||
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
||||
createdAt: 1783183911244
|
||||
updatedAt: 1783278726067
|
||||
version: 6
|
||||
---
|
||||
Pour créer des sprints, j'aimerais une inteface de création dans laquelle je pourrais facilement ajouter/enlever des tickets de mes différents sprint
|
||||
@ -1,6 +0,0 @@
|
||||
---
|
||||
issueRef: "#12"
|
||||
version: 5
|
||||
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
||||
updatedAt: 1783312900907
|
||||
---
|
||||
@ -1,15 +0,0 @@
|
||||
---
|
||||
id: "fb8a73f9-c871-4513-aa09-b35fbbef637a"
|
||||
number: 12
|
||||
title: "Checkbox pour les filters des tickets"
|
||||
status: "closed"
|
||||
priority: "low"
|
||||
links: []
|
||||
agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
|
||||
createdBy: {"kind":"user"}
|
||||
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
||||
createdAt: 1783184054842
|
||||
updatedAt: 1783312900907
|
||||
version: 5
|
||||
---
|
||||
Pour les filtres des tickets, j'aimerais qu'on ai une checkbox plutot que la selection d'un seul filtre, de façon a pouvoir faire des combinaisons de plusieurs priorité et de plusieurs status par exemple
|
||||
@ -1,6 +0,0 @@
|
||||
---
|
||||
issueRef: "#13"
|
||||
version: 4
|
||||
updatedBy: {"kind":"user"}
|
||||
updatedAt: 1783329397368
|
||||
---
|
||||
@ -1,16 +0,0 @@
|
||||
---
|
||||
id: "036783fa-9856-4643-8c28-653b93ac36e1"
|
||||
number: 13
|
||||
title: "Server/client mode"
|
||||
status: "open"
|
||||
priority: "low"
|
||||
sprint: "028179b1-eaf4-41e9-9c1f-7c37125117e6"
|
||||
links: []
|
||||
agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
|
||||
createdBy: {"kind":"user"}
|
||||
updatedBy: {"kind":"user"}
|
||||
createdAt: 1783184188272
|
||||
updatedAt: 1783329397368
|
||||
version: 4
|
||||
---
|
||||
J'aimerais pouvoir utiliser IdeA sous forme de client/server. C'est a dire que IdeA aurait son backend sur une machine et son interface qui serait un frontend web. Les agents etc seraient tous côté server. C'est a dire que la cli de Claude serait celle côté serveur, l'interface client ne serait que l'affichage frontend, une UI. Je pense que tout est faisable, il faudrait cependant parler du côté CLI. Est ce qu'il serait possible de garde rle CLI natif comme il est actuellement, de l'afficher côté client tout en gardant l'installation claude code, codex etc côté serveur ? Peut etre qu'en ssh ça passerait ? Ce ticket ne pourra pas être fait en autonomie par un agent sans une review agent-utilisateur avant.
|
||||
@ -1,20 +0,0 @@
|
||||
---
|
||||
issueRef: "#14"
|
||||
version: 7
|
||||
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
||||
updatedAt: 1783456579694
|
||||
---
|
||||
## Production #14 — livrée dans develop (validation e2e live restante)
|
||||
|
||||
Périmètre figé avec l'utilisateur : adapter HTTP OpenAI-compatible **purement additif** (zéro régression Claude/Codex), parité **tool-calling + MCP** complète, canal HTTP natif robuste.
|
||||
|
||||
### Cycle
|
||||
- Cadrage Architect : slug mémoire `ticket14-local-lan-openai-adapter-scoping` (asymétrie CLI-vs-serveur HTTP, port ToolInvoker in-process, reprise sans id provider).
|
||||
- Backend (DevBackend) : variante `StructuredAdapter::OpenAiCompatible`, VO `HttpChatConfig`, `openai_compat.rs`, port `ToolInvoker` déléguant à la même OrchestratorService que le MCP. GO QA (domain 467 / application 530 / infrastructure 523 / app-tauri 247, 0 échec). Défaut réel corrigé : timeout post-contact mappé Io.
|
||||
- Frontend (DevFrontend) : types DTO miroir, wizard/settings (endpoint/model/apiKeyEnv=nom de var/timeouts, validation miroir backend), profil de référence Ollama éditable, erreur endpoint rendue via bannière role="alert". GO QA (tsc 0 + vitest 59 fichiers / 566 tests, 0 échec). Défaut réel corrigé : erreur endpoint invisible dans le DOM.
|
||||
|
||||
### Git
|
||||
- Backend `aab4bca`, frontend `d89380c`, merge `--no-ff` `3c6cd04` → develop. Branche feature supprimée. **Local uniquement, rien poussé.**
|
||||
|
||||
### Reste à faire (hors code)
|
||||
- Validation e2e **live contre un vrai endpoint Ollama/LAN** : lancement cellule, conversation headless, reprise, délégation inter-agents, vivacité/timeout, endpoint indisponible/modèle absent (critère d'acceptation n°7). Non exercée en tests automatisés — c'est la raison du statut QA plutôt que closed.
|
||||
@ -1,75 +0,0 @@
|
||||
---
|
||||
id: "0c1f1991-b6db-47b7-bbef-2478bc7874ab"
|
||||
number: 14
|
||||
title: "Integration de profils IA locaux/LAN comme profils IdeA canoniques"
|
||||
status: "qa"
|
||||
priority: "medium"
|
||||
sprint: null
|
||||
links: []
|
||||
agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
|
||||
createdBy: {"kind":"user"}
|
||||
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
||||
createdAt: 1783184495846
|
||||
updatedAt: 1783456579694
|
||||
version: 7
|
||||
---
|
||||
Objectif : permettre à IdeA d'utiliser des modèles hébergés localement ou sur le réseau local, par exemple Qwen via Ollama ou un runtime Docker exposant une API, avec le même niveau d'intégration produit que les profils Claude Code et OpenAI Codex CLI.
|
||||
|
||||
La finalité n'est pas un simple profil custom lancé dans un terminal brut. Ces profils doivent devenir de vrais profils IA IdeA : sélectionnables, lançables depuis les cellules, pilotés par la conversation headless canonique, compatibles avec les mécanismes de conversation/reprise, et utilisables par l'orchestration de la même manière que Claude/Codex.
|
||||
|
||||
## Cible produit
|
||||
|
||||
Ajouter une famille de profil structuré pour serveurs de modèles locaux ou LAN, idéalement basée sur une API HTTP compatible OpenAI/Ollama :
|
||||
|
||||
- endpoint configurable (`localhost`, machine LAN, container Docker, etc.) ;
|
||||
- modèle configurable (`qwen...`, autre modèle local) ;
|
||||
- authentification optionnelle via nom de variable d'environnement, jamais clé en clair ;
|
||||
- profil visible et sélectionnable dans IdeA comme Claude/Codex ;
|
||||
- cellule IdeA utilisable de façon canonique : conversation headless, historique, reprise, délégation, affichage des réponses et état de vivacité.
|
||||
|
||||
## Contraintes importantes
|
||||
|
||||
- Ne pas considérer le mode PTY/TUI comme suffisant pour ce ticket.
|
||||
- Éviter une dépendance obligatoire à `ollama`, `docker` ou une commande shell quand une API HTTP suffit.
|
||||
- Étudier explicitement les impacts commandes/headless :
|
||||
- adapter HTTP natif ;
|
||||
- wrapper CLI éventuel ;
|
||||
- Docker/LAN ;
|
||||
- sandbox et permissions ;
|
||||
- absence ou présence de tool-calling/MCP côté modèle local.
|
||||
- Le résultat doit s'intégrer dans le modèle existant `StructuredAdapter` / `AgentSessionFactory`, pas contourner le runtime IA d'IdeA.
|
||||
|
||||
## Travail attendu
|
||||
|
||||
1. Ajouter un adapter structuré pour modèle local/LAN, par exemple `StructuredAdapter::OpenAiCompatible` ou `LocalChat`.
|
||||
2. Étendre le modèle de profil pour porter la configuration nécessaire : endpoint, model, apiKeyEnv optionnel, timeouts/liveness si nécessaire.
|
||||
3. Implémenter une session headless `AgentSession` :
|
||||
- `send(prompt)` ;
|
||||
- émission de `ReplyEvent` ;
|
||||
- gestion propre des erreurs réseau/modèle ;
|
||||
- conversation id ou stratégie de reprise compatible avec le modèle IdeA.
|
||||
4. Brancher l'adapter dans `StructuredSessionFactory`.
|
||||
5. Rendre ces profils sélectionnables dans le wizard/settings au même titre que Claude/Codex.
|
||||
6. Ajouter un profil de référence local, par exemple “Ollama / OpenAI-compatible local model”, éditable.
|
||||
7. Vérifier l'intégration avec :
|
||||
- lancement depuis une cellule ;
|
||||
- conversation headless ;
|
||||
- reprise ;
|
||||
- changement de profil ;
|
||||
- délégation inter-agents quand applicable ;
|
||||
- état de vivacité/timeout ;
|
||||
- erreurs endpoint indisponible/modèle absent.
|
||||
|
||||
## Critères d'acceptation
|
||||
|
||||
- Je peux configurer un profil Qwen hébergé via Ollama ou endpoint LAN.
|
||||
- Je peux créer/lancer un agent IdeA avec ce profil comme avec Claude/Codex.
|
||||
- La cellule utilise le chemin headless structuré, pas un terminal brut PTY.
|
||||
- Les conversations apparaissent et se comportent comme les conversations Claude/Codex.
|
||||
- La reprise ne mélange pas l'id logique IdeA avec un éventuel id provider.
|
||||
- Un endpoint indisponible produit une erreur propre dans l'UI, sans bloquer IdeA.
|
||||
- Les dépendances à `ollama`, Docker ou une CLI externe sont documentées et non imposées si le mode HTTP suffit.
|
||||
- Tests backend couvrant factory, session adapter, erreurs HTTP et sérialisation du profil.
|
||||
- Tests frontend couvrant configuration/sélection du nouveau profil.
|
||||
|
||||
Review agent-user requise avant démarrage d'implémentation pour figer le périmètre exact : HTTP natif uniquement, support d'un wrapper CLI, et niveau attendu de tool-calling/MCP pour les modèles locaux.
|
||||
@ -1,6 +0,0 @@
|
||||
---
|
||||
issueRef: "#15"
|
||||
version: 2
|
||||
updatedBy: {"kind":"user"}
|
||||
updatedAt: 1783329462104
|
||||
---
|
||||
@ -1,22 +0,0 @@
|
||||
---
|
||||
id: "5de121f3-1cd1-4a73-bcab-b0a43a7c257f"
|
||||
number: 15
|
||||
title: "Limites de session — re-livraison automatique parquée au reset (stretch B5, délégation durable)"
|
||||
status: "open"
|
||||
priority: "low"
|
||||
sprint: "d8f3f37b-87ca-4509-9116-45a99bc711df"
|
||||
links: [{"target":"#7","kind":"dependsOn"}]
|
||||
agentRefs: []
|
||||
createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
||||
updatedBy: {"kind":"user"}
|
||||
createdAt: 1783208599385
|
||||
updatedAt: 1783329462104
|
||||
version: 2
|
||||
---
|
||||
Extrait du cadrage Architect du ticket #7 (baseline livrée : propagation inter-agent B1→B3 + F1/F2). Stretch non retenu dans #7.
|
||||
|
||||
Objectif : quand A délègue à B via idea_ask_agent et que B atteint sa limite, au lieu de demander à A de ré-interroger après le reset, PARQUER le waiter de A par (requester,target) ; au execute_resume de B (reprise auto au reset), RE-LIVRER la tâche d'origine et router la complétion vers le waiter de A s'il est encore vivant (sinon drop, contrainte in-memory).
|
||||
|
||||
Coût/risque (Architect) : rapproche du modèle de « délégation durable » tout en restant in-memory → fragile aux redémarrages/interruptions de A, ré-introduit une forme de blocage long côté A. À rattacher au design durable-delegation-runtime-agent-identity-design plutôt que de le traiter en rustine in-memory.
|
||||
|
||||
Dépend de : #7 (baseline inter-agent B1→B3). Voir mémoire ticket7-session-limit-interagent-cadrage.
|
||||
@ -1,6 +0,0 @@
|
||||
---
|
||||
issueRef: "#16"
|
||||
version: 7
|
||||
updatedBy: {"kind":"user"}
|
||||
updatedAt: 1783405334263
|
||||
---
|
||||
@ -1,17 +0,0 @@
|
||||
---
|
||||
id: "0a3585f0-9774-4109-a4e3-746dc5b2a4b2"
|
||||
number: 16
|
||||
title: "[UI] réorganisation des menus"
|
||||
status: "closed"
|
||||
priority: "medium"
|
||||
sprint: null
|
||||
links: []
|
||||
agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
|
||||
createdBy: {"kind":"user"}
|
||||
updatedBy: {"kind":"user"}
|
||||
createdAt: 1783329576091
|
||||
updatedAt: 1783405334263
|
||||
version: 7
|
||||
---
|
||||
J'aimerais réorganiser les mesnus de façon à être un peu plus proche de l'interface d'un IDE plus classique. J'aiemrais plutot avoir des menu déroulant en haut de la fenetre que d'avoir cette barre latérale
|
||||
Les menus déroulant pourraient afficher des fenetres flottantes, ce qui laisserait plus de place pour l'affichage.
|
||||
@ -1,6 +0,0 @@
|
||||
---
|
||||
issueRef: "#17"
|
||||
version: 10
|
||||
updatedBy: {"kind":"user"}
|
||||
updatedAt: 1783405334977
|
||||
---
|
||||
@ -1,16 +0,0 @@
|
||||
---
|
||||
id: "66aaef66-c70a-4153-81e9-a8f323686092"
|
||||
number: 17
|
||||
title: "[UI] fenetre de gestion de tickets"
|
||||
status: "closed"
|
||||
priority: "medium"
|
||||
sprint: null
|
||||
links: [{"target":"#16","kind":"dependsOn"},{"target":"#18","kind":"dependsOn"}]
|
||||
agentRefs: []
|
||||
createdBy: {"kind":"user"}
|
||||
updatedBy: {"kind":"user"}
|
||||
createdAt: 1783329807682
|
||||
updatedAt: 1783405334977
|
||||
version: 10
|
||||
---
|
||||
J'aimerais une fenetre dédiée à la gestion des tickets. Autant pour le listing que pour la création/edition des tickets. Dans un même temps, j'aimerais qu'on améliore la gestion des tickets lié lorsque l'on édite les tickets en utilisant la popup du ticket #18. J'aiemrais aussi que l'agent permettant l'écriture des tickets soit proposé de façon plus évidante. Je pense qu'un bouton en bas à droite de la fenetre d'édition ouverte serait bien.
|
||||
@ -1,6 +0,0 @@
|
||||
---
|
||||
issueRef: "#18"
|
||||
version: 9
|
||||
updatedBy: {"kind":"user"}
|
||||
updatedAt: 1783405335941
|
||||
---
|
||||
@ -1,16 +0,0 @@
|
||||
---
|
||||
id: "5c17d6d3-c537-45b1-a17e-9c4edee963d1"
|
||||
number: 18
|
||||
title: "[UI] Créer une popup de selection de ticket"
|
||||
status: "closed"
|
||||
priority: "medium"
|
||||
sprint: null
|
||||
links: []
|
||||
agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
|
||||
createdBy: {"kind":"user"}
|
||||
updatedBy: {"kind":"user"}
|
||||
createdAt: 1783330038271
|
||||
updatedAt: 1783405335941
|
||||
version: 9
|
||||
---
|
||||
Pour différentes feature comme la création de sprint ou même le link d'un ticket à d'autres, il est necessaire de selectionner un ticket. Pour ça j'aimerais un popup qui puisse être utilisée dans ces différentes features pour la selection d'un ticket. Il faudrait une barre de recherche ainsi que la possibilité d'appliquer des filtres sur l'avancée ainsi que la priorité des tickets, comme pour le listing principal des tickets.
|
||||
@ -1,6 +0,0 @@
|
||||
---
|
||||
issueRef: "#19"
|
||||
version: 8
|
||||
updatedBy: {"kind":"user"}
|
||||
updatedAt: 1783405337651
|
||||
---
|
||||
@ -1,16 +0,0 @@
|
||||
---
|
||||
id: "b1c84dd2-cef7-4e48-a501-1a30eedb02f2"
|
||||
number: 19
|
||||
title: "[UI] implémentation de la popup de selection de ticket dans la création d'un sprint"
|
||||
status: "closed"
|
||||
priority: "low"
|
||||
sprint: null
|
||||
links: [{"target":"#18","kind":"dependsOn"}]
|
||||
agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
|
||||
createdBy: {"kind":"user"}
|
||||
updatedBy: {"kind":"user"}
|
||||
createdAt: 1783330352910
|
||||
updatedAt: 1783405337651
|
||||
version: 8
|
||||
---
|
||||
Lors de l'edition d'un sprint, j'aimerais que pour selectionner un ticket, ça soit la popup de selection de ticket qui soit utilisée
|
||||
@ -1,6 +0,0 @@
|
||||
---
|
||||
issueRef: "#2"
|
||||
version: 2
|
||||
updatedBy: {"kind":"user"}
|
||||
updatedAt: 1783184142093
|
||||
---
|
||||
@ -1,24 +0,0 @@
|
||||
---
|
||||
id: "0a492d45-e195-4df7-a2ad-65649372abf0"
|
||||
number: 2
|
||||
title: "Tâches de fond — dette A : PtyPort::wait/try_wait + tee live UI + robustesse détection de fin"
|
||||
status: "open"
|
||||
priority: "low"
|
||||
links: []
|
||||
agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
|
||||
createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
||||
updatedBy: {"kind":"user"}
|
||||
createdAt: 1783082860742
|
||||
updatedAt: 1783184142093
|
||||
version: 2
|
||||
---
|
||||
Dette issue de l'arbitrage B8 (mémoire projet: b8-arbitration-outcomes, point 1).
|
||||
|
||||
B8 a été accepté sans rendu live des tâches de fond. Le cœur complétion→wake fonctionne, mais la détection de fin du runner repose sur l'EOF du stream PTY single-consumer, ce qui est fragile et empêche un tee UI (une re-souscription UI casserait la détection EOF).
|
||||
|
||||
Reste à faire :
|
||||
- Ajouter `PtyPort::wait` / `try_wait` pour découpler la détection d'exit de la consommation d'output (retirer l'EOF-comme-proxy-de-fin).
|
||||
- Une fois découplé, brancher un tee de la sortie PTY vers l'UI pour le rendu live des tâches de fond (F-live).
|
||||
- NE PAS introduire de broadcast multi-consommateur (décision Architect).
|
||||
|
||||
Périmètre touchant un port figé (PtyPort) : cadrage Architect requis avant implémentation.
|
||||
@ -1,6 +0,0 @@
|
||||
---
|
||||
issueRef: "#20"
|
||||
version: 2
|
||||
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
||||
updatedAt: 1783331176736
|
||||
---
|
||||
@ -1,26 +0,0 @@
|
||||
---
|
||||
id: "1be19ee5-fd03-42ea-8df6-da18704807a9"
|
||||
number: 20
|
||||
title: "[Backend] Dette ticket_list — matching #ref dans text + curseur opaque/stable"
|
||||
status: "open"
|
||||
priority: "low"
|
||||
sprint: null
|
||||
links: [{"target":"#18","kind":"relatesTo"}]
|
||||
agentRefs: []
|
||||
createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
||||
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
||||
createdAt: 1783331172226
|
||||
updatedAt: 1783331176736
|
||||
version: 2
|
||||
---
|
||||
Dette backend identifiée pendant le cadrage du sprint UI rework (gate G4), non bloquante pour la popup #18 qui démarre sur le contrat actuel.
|
||||
|
||||
Deux écarts sur la commande `ticket_list` (handler `crates/app-tauri/src/tickets.rs:681`, filtre store `crates/infrastructure/src/issues.rs`) :
|
||||
|
||||
1. Recherche `text` : appliquée serveur sur titre (issues.rs:322) + description/carnet (issues.rs:326/465) mais PAS sur le `#ref`/numéro de ticket. Étendre le matching `text` à `issue_ref` pour permettre la recherche par numéro dans la popup de sélection.
|
||||
|
||||
2. `cursor` : actuellement un offset numérique parsé en usize avec fallback silencieux à 0 si invalide (tickets.rs:1231), non opaque et non stable face à des mutations entre pages. Contractualiser un curseur opaque + stable (ordre déterministe préservé).
|
||||
|
||||
Garde G3-bis déjà en place côté frontend : `TicketPicker`/`useTicketSearch` traitent `cursor` comme un token opaque (jamais construit/incrémenté côté client), donc la migration vers un curseur opaque backend n'exigera AUCUN changement frontend — cette dette est non-breaking.
|
||||
|
||||
statuses[]/priorities[] sont conformes (OR intra-facette, AND inter-facette, testés) — rien à faire de ce côté.
|
||||
@ -1,6 +0,0 @@
|
||||
---
|
||||
issueRef: "#21"
|
||||
version: 7
|
||||
updatedBy: {"kind":"user"}
|
||||
updatedAt: 1783437364397
|
||||
---
|
||||
@ -1,16 +0,0 @@
|
||||
---
|
||||
id: "4ffe9f90-2264-4861-b7da-f5535b0a622f"
|
||||
number: 21
|
||||
title: "[UI] pouvoir trier les ticket par..."
|
||||
status: "closed"
|
||||
priority: "low"
|
||||
sprint: null
|
||||
links: [{"target":"#16","kind":"dependsOn"},{"target":"#18","kind":"dependsOn"}]
|
||||
agentRefs: []
|
||||
createdBy: {"kind":"user"}
|
||||
updatedBy: {"kind":"user"}
|
||||
createdAt: 1783331825658
|
||||
updatedAt: 1783437364397
|
||||
version: 7
|
||||
---
|
||||
J'aiemrais qu'on ajoute une option "trier par..." dans la popup de selection des tickets et dans la liste principale des tickets. On pourrait trier par numéro de ticket, priorité, status, ou titre du ticket. Avec chaque fois croissant/decroissant.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user