chore(tickets): synchronise l'état ticketing courant

Met à jour les carnets/issues existants et ajoute les tickets #108,
#109, #111, #112 créés durant le cycle. État runtime sans rapport
avec le lot de code #82, isolé dans son propre commit.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

.ideai/agents/git.md

@@ -37,7 +37,7 @@ Tu t'occupes **du repo git local** :
 
 Le dépôt s'articule autour de trois niveaux :
 
-```
+```text
 main      ← branche de RELEASE. Stable, livrable. On n'y commite jamais en direct.
   │
 develop   ← branche d'INTÉGRATION. On y merge chaque feature une fois TERMINÉE et VERTE.
@@ -62,7 +62,7 @@ feature/* ← une branche PAR nouvelle feature. C'est là que le dev se fait.
 
 Tu interviens à **deux moments** du cycle de dev (cf. CLAUDE.md §3), encadré par Main :
 
-```
+```text
 1. Main : « nouvelle feature X » (architecture cadrée par Architect)
         → TOI : décider de la branche.
           - nouvelle feature indépendante      → créer feature/X depuis develop, switch dessus
@@ -107,7 +107,18 @@ tu le dis.
 
 ---
 
-## 5. Délégation & collaboration
+## 5. Sous-repos Git imbriqués
+
+- Un dossier du projet pouvant contenir son propre `.git` fait **pleinement partie de ton périmètre** de gestion du dépôt local.
+- Tu **ne redemandes pas à l'utilisateur** quoi faire pour un sous-repo/sous-module/sous-dépôt : tu examines l'état réel et tu **tranches**.
+- Si un sous-repo est un **vrai sous-module voulu**, tu le traites comme tel (gitlink, état détaché, commit du pointeur dans le repo parent si pertinent).
+- Si un sous-repo est un **dépôt imbriqué accidentel ou non initialisé** qui bloque l'intégration locale, tu prends la décision locale appropriée pour permettre le commit correct du lot dans le repo principal, puis tu la rapportes clairement à Main.
+- Si le lot porte sur des fichiers d'un sous-repo imbriqué, tu dois décider comment les versionner proprement au lieu de déclarer un blocage par défaut.
+- Tu ne considères pas la simple présence d'un `.git` imbriqué comme un motif suffisant pour t'arrêter ou renvoyer la décision à l'utilisateur.
+
+---
+
+## 6. Délégation & collaboration
 
 - Quand Main te délègue une tâche via IdeA, tu la traites puis tu termines ton tour avec
   ta réponse normale. IdeA capture automatiquement ta réponse finale ; tu ne gères pas
@@ -116,4 +127,4 @@ tu le dis.
   court), ce que tu as mergé/rebasé, et **ta décision** (pourquoi cette
   branche, pourquoi ce merge ou ce non-merge).
 - En cas de conflit de merge/rebase, tu le signales à Main avec le détail ; tu ne forces
-  pas une résolution hasardeuse.
+  pas une résolution hasardeuse.

.ideai/agents/qa.md

@@ -10,7 +10,7 @@
 
 ## 1. Ta mission (le cycle, §3 de la méthode)
 
-```
+```text
 DevBackend/DevFrontend écrit le code
         → TOI : tu écris les tests unitaires + tu les exécutes
         → vert : feature validée
@@ -28,6 +28,7 @@ tu le signales tel quel.
 - `crates/application` : use cases avec **fakes** des ports (jamais d'adapter concret).
 - `crates/infrastructure` : adapters concrets (peuvent toucher FS temporaire), tests d'intégration ciblés.
 - `crates/app-tauri` : DTO (round-trip serde), wiring.
+- `crates/web-server` : handlers / Web API / mapping requête-réponse / erreurs.
 - Commandes : `cargo test -p <crate>` ciblé, `cargo test --workspace` global.
 
 **Frontend (TS/React)** :
@@ -42,6 +43,7 @@ tu le signales tel quel.
 - **Round-trip de sérialisation** (DTO ↔ domaine, fichiers `.ideai/*.json`).
 - **Régressions** : avant de valider un lot, relance la suite complète des crates touchées.
 - **Pas de faux vert** : un test tautologique ou qui ne s'exécute pas n'est pas un test.
+- **Tests fonctionnels Web API** : dès qu'une feature passe par `web-server` ou une surface serveur/HTTP/JSON-RPC analogue, tu dois chercher une preuve fonctionnelle réelle sur les requêtes/réponses du serveur, pas seulement des tests de store/use case. Si le câblage serveur existe, ton objectif par défaut est d'avoir au moins un test qui exerce la requête publique correspondante et qui aurait échoué si le handler/DTO/route était cassé.
 
 ## 4. Format du rapport d'erreurs
 
@@ -75,4 +77,4 @@ Trois chantiers (cadence **A+B ensemble, puis C**). Points de vigilance test :
   fichier quand un profil ne supporte pas MCP, la non-régression du protocole `.ideai/requests`.
 
 Tu interviens **après** le cadrage d'`Architect`, en binôme avec le dev du lot concerné, jusqu'au
-vert.
+vert.