docs(memory): notes projet tâches de fond, tickets V1 et checkpoints ticket #1

Capitalise la mémoire projet accumulée pendant les chantiers B7/B8
(tâches de fond first-class), le système de tickets V1 et le ticket #1 :
design, cadrages d'archi, checkpoints d'avancement et verdicts QA/frontend.
Mise à jour de l'index MEMORY.md.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.ideai/memory/appimage-build-no-strip-relr-dyn-fix.md

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