chore(ideai): état runtime — tickets, mémoire, tâches de fond

État d'exécution accumulé (tickets créés/mis à jour hors #43, notes de
mémoire, tâche de fond) capturé au moment du commit de la feature.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
2026-07-22 07:37:19 +02:00
parent ac726d075e
commit 98fb05447d
56 changed files with 5499 additions and 135 deletions

View File

@ -65,3 +65,5 @@
- [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

View File

@ -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).

View File

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

View File

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