chore(idea): bookkeeping tickets #219-#223 et index #224

.ideai/tickets/223/carnet.md

@@ -0,0 +1,66 @@
+---
+issueRef: "#223"
+version: 3
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+updatedAt: 1787578200000
+---
+## Triage 2026-08-17
+- Symptôme utilisateur:
+  - le startup MCP échoue;
+  - l'utilisateur précise qu'il utilise la surface Web fournie par l'AppImage IdeA, pas le binaire Web standalone.
+- Vérifications statiques:
+  - `crates/app-tauri/src/lib.rs`: le binaire AppImage route `--serve` vers `server::run_from_args(...)`;
+  - `crates/app-tauri/src/server.rs`: ce wrapper appelle `web_server::run_from_args(...)`;
+  - `crates/app-tauri/src/commands.rs`: `open_project_for_adapter(...)` appelle `state.ensure_orchestrator_watch(&output.project)`;
+  - `crates/web-server/src/lib.rs`: `invoke_open_project(...)` se contente de `resolve_project_readonly(...)` et sérialise le DTO.
+- Hypothèse principale:
+  - en surface Web embarquée, l'ouverture de projet ne passe pas par la logique partagée qui réconcilie l'état et démarre `ensure_orchestrator_watch`;
+  - conséquence probable: watcher/orchestrateur/MCP non armés pour le projet ouvert via HTTP, alors que le desktop le fait.
+- Références de code utiles:
+  - `crates/app-tauri/src/commands.rs:462`
+  - `crates/web-server/src/lib.rs:3094`
+  - `crates/backend/src/lib.rs:3301`
+- Travail attendu:
+  - Architect: valider la cause racine et le contrat de convergence desktop/Web;
+  - Git: décider la branche locale;
+  - DevBackend: faire passer l'ouverture de projet Web par le même flux que le desktop, sans régression sur les lectures read-only non concernées;
+  - QA: prouver que le startup MCP remarche réellement en surface Web embarquée, avec commandes/sorties réelles.
+
+## Implémentation 2026-08-17
+- Correctif appliqué dans `crates/web-server/src/lib.rs`.
+- Changement:
+  - `invoke_open_project(...)` ne fait plus une simple lecture read-only;
+  - nouveau helper `open_project_for_web(...)` qui exécute `open_project`, réconcilie layouts/live-state/background tasks, arme `ensure_orchestrator_watch`, puis lance `reconcile_claude_run_dirs`, comme le flux desktop.
+- Test ajouté:
+  - `authorized_open_project_arms_orchestrator_watch`
+  - preuve: après `open_project` via `/api/invoke`, `state.app.open_project_ids()` contient bien le projet ouvert.
+
+## QA 2026-08-17
+- Commandes:
+  - `cargo test -p web-server authorized_open_project -- --nocapture`
+  - `cargo test -p web-server web_invoke_routes_agent_commands -- --nocapture`
+- Résultat:
+  - `authorized_open_project_returns_readonly_project_dto ... ok`
+  - `authorized_open_project_arms_orchestrator_watch ... ok`
+  - `web_invoke_routes_agent_commands ... ok`
+- Verdict:
+  - `QA` sur preuve automatisée ciblée.
+  - Validation live restante utile: vérifier en AppImage surface Web qu'un projet ouvert puis un agent MCP-capable lancé déclenche bien un startup MCP réussi de bout en bout.
+
+## Reprise 2026-08-20
+- Signal utilisateur:
+  - "le mcp fail encore sur la version web".
+- Vérification de l'état courant du code:
+  - `crates/web-server/src/lib.rs` contient a nouveau le helper `open_project_for_web(...)`;
+  - le flux HTTP `invoke_open_project(...)` n'utilise plus `resolve_project_readonly(...)` mais execute `open_project`, puis `reconcile_layouts`, `reconcile_live_state`, `reconcile_background_tasks`, `ensure_orchestrator_watch(&output.project)` et `reconcile_claude_run_dirs(&output.project)`;
+  - `crates/web-server/src/bin/idea-serve.rs` route maintenant aussi le sous-mode `mcp-server` vers `backend::mcp_bridge::run_mcp_bridge(...)`;
+  - `crates/backend/src/lib.rs` exporte le module partage `mcp_bridge` pour reutiliser le meme pont stdio<->loopback entre desktop et binaire web.
+- Validation automatisee du 2026-08-20:
+  - `cargo check -p web-server` -> OK
+  - `cargo test -p web-server authorized_open_project_arms_orchestrator_watch -- --nocapture` -> OK
+  - `cargo test -p web-server web_root_candidates_include_appimage_resource_dir -- --nocapture` -> OK
+  - `cargo test -p web-server web_invoke_routes_agent_commands -- --nocapture` -> OK
+- Conclusion de pilotage:
+  - le correctif backend/web pour re-armer l'orchestrateur/MCP sur `open_project` web est present dans l'arbre courant et vert en tests cibles;
+  - le ticket passe en `QA`;
+  - fermeture a garder conditionnee a une preuve live AppImage/web montrant qu'un agent MCP-capable lance depuis la surface web demarre bien son MCP de bout en bout.

.ideai/tickets/223/issue.md

@@ -0,0 +1,17 @@
+---
+id: "6d08f613-f1b7-4e16-91c2-e1b94833d6e1"
+number: 223
+title: "MCP startup en surface Web embarquée: open_project n'arme pas l'orchestrateur comme le desktop"
+status: "QA"
+priority: "high"
+sprint: null
+links: []
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+createdAt: 1786992000000
+updatedAt: 1787578200000
+version: 4
+---
+En surface Web servie par l'AppImage IdeA, le startup MCP échoue alors qu'il fonctionnait auparavant. Le diagnostic initial pointe un écart de câblage entre le chemin desktop/Tauri et le chemin HTTP Web: l'ouverture de projet desktop appelle `open_project_for_adapter(...)`, qui exécute `state.ensure_orchestrator_watch(&output.project)`, tandis que le routeur Web `invoke_open_project(...)` ne fait actuellement qu'un `resolve_project_readonly(...)` sans armer l'orchestrateur/MCP du projet.