# 🔁 REX — Retour d'Expérience OLYMPUS

> **Inspiration** : pattern industriel (nucléaire, aéronautique). Quand un problème survient, on l'analyse, on met en place une mesure pour qu'il ne se reproduise plus, et on documente.

---

## 📐 Format d'un REX

```md
### YYYY-MM-DD · [Titre court du problème]
**Niveau** : 🟢 mineur · 🟡 modéré · 🔴 critique
**Contexte** : ce qui se passait
**Problème observé** : ce qui n'a pas marché
**Cause racine** : pourquoi (analyse 5-pourquoi si pertinent)
**Mesure corrective** : ce qu'on met en place
**Vérification** : comment savoir que ça ne se reproduit pas
**Statut** : 🔄 en cours · ✅ résolu · ❌ abandonné
```

---

## 📥 REX en cours / récents

### 2026-05-18 · LGS V196 — Session fiabilisation + vague plugins
**Niveau** : 🟢 mineur (améliorations préventives, rien de cassé)

**Contexte** : Session 104-SUPER-GOD. LGS V2 stable, Vivien demande fiabilisation générale + compatibilité future.

**Problèmes corrigés** :
- Chemin Python hardcodé dans 5 fichiers → `find_pythonw()` centralisé dans `lgs_common.py`
- Logs sans rotation (grossissement infini) → `RotatingFileHandler` 5 MB × 3
- NexusBadge faisait 4 requêtes HTTP par refresh (dont `openapi.json` 457 paths) → réduit à 1-2
- Badge affichait codename interne "Wake 3 voies" → renommé "NEXUS" stable
- Goku/Vegeta polluaient la barre sans être câblés → mis en veille proprement
- Mini Claude crashait si `bootstrap_olympus_paths()` retournait None → fallback `F:\OLYMPUS`
- Mini Claude V2 fallback jamais déclenché → bascule sur V1 après 3 échecs
- LGS absent du démarrage Windows → ajouté dans `start_olympus_all.bat` étape 6
- Pas de plugin loader → `_start_plugins()` scan `plugins/*/manifest.json` au boot

**Mesures mises en place** :
- `lgs_common.find_pythonw()` — un seul endroit pour tous les scripts
- Bouton 🔄 dans Mini-Code pour tuer claude.exe bloqué
- Conscience Mini-Claude enrichie : date/heure, projet actif, santé NEXUS
- `lgs_prompt.md` mis à jour section V196
- `.exe` stub recompilé avec chemin Python dynamique

**Statut** : ✅ résolu

---

### 2026-05-11 · `core_exec` MCP deadlock pipe Windows 64 KB
**Niveau** : 🔴 critique (crash MCP serveur, 33 outils tombent en cascade)

**Contexte** : L'outil `core_exec` du MCP `olympus-core` (`C:/OLYMPUS/AGORA/connecteurs_maison/olympus-core/olympus_core.py`) exécutait des commandes PowerShell/cmd via `subprocess.run(capture_output=True, timeout=N)`. Cas observés : 18-WORD a lancé un script Python qui chargeait matplotlib + python-docx (verbose stdout). 04GOD a lancé `Start-Process -FilePath python.exe -Wait` sur une GUI PyQt persistante (LGS).

**Problème observé** :
- `core_exec` moulinait 6 à 15 minutes au lieu de respecter `timeout_sec`
- Le MCP serveur olympus-core devenait silencieux, Claude Desktop le déclarait unresponsive et tuait l'ensemble
- Effet domino : les 4 MCPs `olympus-*` se déconnectaient (33 outils perdus)
- Sortie au final : `33 deferred tools no longer available` dans le system reminder
- Conscience G/T tombait à 0/0 en cascade

**Cause racine (5-pourquoi)** :
1. Pourquoi `core_exec` mouline ? → `subprocess.run(capture_output=True)` ne lit stdout/stderr qu'après `wait()`.
2. Pourquoi `wait()` ne retourne pas ? → Le subprocess est bloqué sur `write()` car le pipe est plein.
3. Pourquoi le pipe est plein ? → Sur Windows, les pipes anonymes ont un buffer de ~**64 KB**. Un python.exe avec matplotlib cold + python-docx + verbose dépasse facilement.
4. Pourquoi pas un timeout effectif ? → Le `TimeoutExpired` côté `subprocess.run` se déclenche **mais ne tue pas les petits-fils orphelins** (`Start-Process` détache par défaut). Le MCP serveur reste dans un état corrompu après l'exception.
5. Pourquoi le MCP serveur crashe au lieu de retourner une erreur ? → Aucune protection try/except autour de `subprocess.run` n'attrapait certains états (orphelins zombies, buffer corrompu). L'exception remontait au handler FastMCP et tuait l'event loop.

**Mesure corrective** (agent technique 2026-05-11 matin, fichier patché en place) :
1. ✅ **Remplacer `subprocess.run` par `subprocess.Popen` + 2 threads daemon** qui drainent stdout/stderr en continu par chunks 4 KB → pipe JAMAIS plein → plus de deadlock pipe.
2. ✅ **`CREATE_NEW_PROCESS_GROUP`** au lancement + **`taskkill /F /T /PID <pid>`** au timeout → tue l'arbre complet (descendants inclus, fini les orphelins).
3. ✅ **Cap dur 60 sec** (`timeout_sec` clampé entre 1 et 60).
4. ✅ **Tronquer stdout/stderr à 100 KB** chacun (au-delà : continue à drainer dans le vide pour ne pas bloquer le subprocess, mais ne renvoie pas dans le contexte Claude).
5. ✅ **Try/except total** : toutes exceptions catch → JSON propre `{ok: false, error: ...}` retourné — aucune remontée à FastMCP, plus de crash MCP serveur.
6. ✅ Backup Mona Lisa avant patch : `C:/OLYMPUS/99_BACKUP/agent_fix_core_exec_20260511_120000/olympus_core.py`.

**Tests de validation** :
- **10/10 PASS** en tests isolés : echo, sortie 250 KB (tronquée à 100 KB), sleep 100 timeout 3s (return 3.2s `killed_tree=True`), sleep 120 timeout 4s (return 4.1s `killed_tree=True`), python + matplotlib cold, cap dur 60s, commande invalide (returncode=1 sans crash), unicode UTF-8.
- **30 itérations stress** dont 10 timeouts → **0 fuite de processus PowerShell** (vérifié via `tasklist`).
- **Validation en production** ce matin : process MCP bloqué (PID 31552) tué manuellement, Claude Desktop a relancé le MCP avec le code patché, `core_files_list` répond instantanément.

**Vérification** :
- Métrique : aucun mouline > 60s sur `core_exec` pendant 30 jours → succès
- Test régression : à chaque modif `olympus_core.py`, relancer `_test_core_exec_isolated.py` (10 cas) — doit toujours 10/10 PASS
- Surveillance : si un chat signale "core_exec mouline", appliquer la procédure de sauvetage (kill PID + Claude Desktop relance le MCP)

**Procédure de sauvetage** (quand un autre chat plante sur core_exec, valable comme fallback) :
```bash
# Trouver le PID du MCP bloqué
powershell "Get-CimInstance Win32_Process -Filter \"Name='python.exe'\" | Where-Object { \$_.CommandLine -like '*olympus_core*' } | Select ProcessId"
# Tuer arbre process
taskkill /F /T /PID <PID>
# Le prochain appel d'outil olympus-core force Claude Desktop à relancer le MCP avec le code patché
```

**Statut** : 🟢 RÉSOLU (code patché en place 2026-05-11 matin, validé en prod, MCP serveur opérationnel)

**Leçons retenues** :
- `subprocess.run(capture_output=True)` est **DANGEREUX sur Windows** dès que la sortie peut dépasser 64 KB
- Toujours préférer `Popen` + threads de drainage pour subprocess long-running
- Pour tuer un subprocess sous Windows, `process.kill()` ne suffit pas → utiliser `taskkill /F /T /PID` (tue l'arbre)
- Un MCP serveur ne doit JAMAIS laisser remonter une exception au handler FastMCP — toujours try/except total
- Pour éviter le crash domino des 4 MCPs olympus-* : la procédure de sauvetage `kill PID` fonctionne sans redémarrer Claude Desktop

---

### 2026-05-11 · OfficeCLI `set` accepte path DOM footer/header sans `raw-set` ni `--part`
**Niveau** : 🟢 mineur (découverte positive, lève la limite "header/footer non scannés" de `/api/word/replace`)
**Contexte** : Pendant VAGUE 1 TÂCHE 6, on cherchait à modifier le footer d'un `.docx` ouvert dans Word sans le fermer. Hypothèse initiale : il faut passer par `raw <file> /<part_name>` ou un mécanisme `--part` pour cibler le footer (qui est une part OOXML séparée de `/word/document.xml`).
**Problème observé** : `raw <file> /footer1` retourne `"(footer[0] not found)"` — la syntaxe `/footer1` n'est pas reconnue comme nom de part. Plusieurs tentatives infructueuses sur le format part-name.
**Cause racine** : sur-interprétation de l'OOXML. La commande `set` d'OfficeCLI utilise des **DOM paths racine** unifiés (préfixés `/body/`, `/footer[N]/`, `/header[N]/`, `/comments/`, etc.). Pas besoin de cibler la part XML par son nom de fichier ; `set` route automatiquement le DOM path vers la part correspondante.
**Mesure corrective** :
1. **Workflow standard footer/header** : `query <file> --xpath "<texte>"` → récupère path DOM `/footer[1]/p[@paraId=...]/r[N]` → `set <file> <path> --prop text="..." --force`. Vérité disque via OOXML brut (`zipfile` → `word/footer1.xml` → `<w:t>`).
2. **Piège verrouillage** : si `watch` est actif sur le doc, `set` écrit OK (lock interne OfficeCLI) MAIS Python ne peut pas relire (`PermissionError WinError 32`). Solution : `unwatch <file>` AVANT toute lecture Python.
3. **Limite résiduelle** : footer multi-runs (formatages mixtes splittés en plusieurs `<w:r>`) → `set` ne touche qu'un run à la fois ; pour replace texte intégral d'un paragraphe stylé, boucler sur les runs ou utiliser `remove` + `add`.
**Vérification** : preuve disque OOXML brut `word/footer1.xml` montre `<w:t>MODIF_T6_OFFICECLI</w:t>` après opération. Documenté `VAGUE_1_WORD_LIVE_COM.md` section T6.
**Statut** : ✅ résolu — workflow gravé dans protocole VAGUE 1 + FUSION

---

### 2026-05-11 · `verify_docx` aveugle au formatting + faux-positif sur typo de clé `expected`
**Niveau** : 🟡 modéré (faux-positifs silencieux dans tests TDD)
**Contexte** : `C:/OLYMPUS/AGORA/modules_maison/officegen/verify.py` permet "Write-then-Read-Verify" pour Office. Mais limité au comptage structurel (paragraphes, tables, headings). VAGUE 1 TÂCHE 7 voulait vérifier que les Q fondamentales du panza doc sont bien en GRAS et que le footer contient "Version 1.2".
**Problème observé** :
1. Champs absents : `read_docx_structure` ne retourne ni `paragraphs_formatting`, ni `headers_text`, ni `footers_text`. Impossible de vérifier bold/italic/color/font sans réimplémenter.
2. **Faux-positif silencieux** : `verify_docx({path}, {"bold_paragraphs_contain": [...]})` retournait `verify_ok: True` parce que la clé n'était pas reconnue mais **ignorée sans bruit**. Pire que de planter : ça mentait honnêtement.
3. Q fondamentales (1.2, 2.2, 3.4...) NON DÉTECTÉES en gras même après ajout du scan, car elles sont dans des **cellules de tableaux**, pas dans `d.paragraphs` racine.
**Cause racine** :
1. Modèle mental insuffisant des classes python-docx : `d.paragraphs` couvre uniquement le body racine, pas le contenu cellule-de-tableau, ni les headers/footers.
2. Pattern "permissive validator" → clé inconnue silencieusement ignorée. Anti-pattern test honnête.
**Mesure corrective** :
1. Scan unifié : `paragraphs_formatting` (body), `table_paragraphs_formatting` (récursif sur cellules + sous-tableaux), `headers_text` + `footers_text` (sur toutes sections, kind default/first_page/even_page).
2. Whitelist `_KNOWN_EXPECTED_KEYS` + diff explicite si clé hors whitelist. Plus jamais de faux-positif silencieux.
3. Méthode TDD strict : RED (test échoue) → GREEN (implém min) → confirm 4/4 PASS sur panza v1.2.
**Vérification** : `C:/OLYMPUS/AGORA/modules_maison/officegen/test_verify_formatting.py` couvre 4 scénarios (structure étendue + bold + italic + footer) ET 1 test négatif (typo `bold_paragraph_contain` → doit échouer avec "clé inconnue").
**Leçon retenue** : tout validateur qui accepte un dict d'options DOIT vérifier que les clés sont connues, sinon il accepte tacitement les typos et ment.
**Statut** : ✅ résolu — verify.py étendu, tests TDD passent

---

### 2026-05-11 · OmniParser : path mismatch V1/V2 + cv2.pyd file-lock empêche install easyocr à chaud
**Niveau** : 🟡 modéré (5ème niveau MIX non opérationnel, mais 4 autres niveaux suffisent pour Office)
**Contexte** : VAGUE 1 TÂCHE 8 — perception pixel via OmniParser-v2 pour valider visuellement le rendu d'un `.docx`. Weights téléchargés OK (1.07 GB), mais `/api/vision/parse` retourne `"Weights manquants"` et `/api/vision/omni_v2/parse_full` retourne `EN_CHANTIER: true`.
**Problème observé** :
1. **2 endpoints au même path** : `api_vision_omni.py` (V2, cherche dans `AGORA/models/omniparser/`) ET `api_win_extras.py` (V1, cherche dans `AGORA/connecteurs_externes/omniparser/weights/`). V1 shadow V2. Endpoint V2 a un `parse_full` stub `EN_CHANTIER: true`.
2. V1 path différent du dossier où `download_weights` écrit → impossible de loader le modèle malgré download réussi.
3. Install `easyocr` dans NEXUS python échoue : `OSError [WinError 5] Accès refusé: 'cv2.pyd'` — NEXUS l'utilise en runtime, lock Windows sur fichier `.pyd`.
**Cause racine** :
1. 2 fichiers AXIOM écrivent le même chemin REST `/api/vision/parse` avec des disques différents → conflit d'architecture, V1 shadow V2.
2. Windows ne permet pas de réécrire un fichier `.pyd` mappé en mémoire par un process running. Pip install échoue donc pour tout module dont une `.pyd` dépendante est déjà loadée par un autre process Python (cas opencv-python via cv2.pyd).
**Mesure corrective** :
1. **Workaround immédiat (appliqué)** : 2 directory junctions Windows (`mklink /J`, pas besoin admin) pour pointer `connecteurs_externes/omniparser/weights/icon_detect` → `AGORA/models/omniparser/icon_detect` (idem pour `icon_caption_florence` → `icon_caption`). Status passe à `weights_yolo_present: true, weights_florence_present: true`.
2. **À faire (follow-up hors scope panza)** : soit (a) implémenter `parse_full` V2 (sortir du stub), soit (b) installer `easyocr` lors d'une maintenance planifiée (stop NEXUS → `<NEXUS_PYTHON>/python.exe -m pip install easyocr` → restart NEXUS), soit (c) supprimer le doublon de routes V1/V2.
3. Note FUSION pour 04GOD inscrite avec scope + paths exacts.
**Vérification** : `weights_count: 2` sur `/api/vision/omni_v2/health`. Junctions visibles via `os.listdir(connecteurs_externes/omniparser/weights/)` → 1033 MB + 38 MB exposés.
**Leçon retenue** : ne JAMAIS register 2 endpoints sur le même path REST dans 2 fichiers différents — c'est ingérable et trompeur. À détecter dans un futur audit AGORA (anti-doublon).
**Statut** : 🟡 partiel — weights + paths OK, mais perception pixel pas opérationnelle. Non bloquant pour le scope panza document.

---

### 2026-05-11 · Word workflow live opérationnel via GetActiveObject + Range.Text + snapshot/restore
**Niveau** : 🟢 mineur (découverte positive, débloque tout le workflow Office)
**Contexte** : VAGUE 1 T9 — tester end-to-end "modifier doc Word ouvert chez Vivien + voir live + rollback". L'hypothèse précédente "Office 2013 cracké force ReadOnly" était partiellement fausse.
**Problème observé** : 4 patterns Find.Execute(Replace=2) testés, tous mentent (returns True + modified_count>0 sans modifier). Undo Word(N) instable car undo stack mélange modifs programmatiques + manuelles.
**Cause racine** :
1. `win32com.client.Dispatch('Word.Application')` lance une instance COM **Embedding** sans login utilisateur → Office 2013 cracké force `doc.ReadOnly = True`. C'est l'origine du bug `/replace` côté serveur (qui utilisait Dispatch).
2. `win32com.client.GetActiveObject('Word.Application')` se branche sur la Word **déjà ouverte par Vivien** → `doc.ReadOnly: False`, modifs possibles.
3. `Find.Execute(Replace=2)` est buggué dans cette version de Word — il signale True sans appliquer le Replacement.Text. **Mais** `Find.Execute(Replace=0)` (juste localiser) + `Selection.Range.Text = replace_text` (assignment direct sur la sélection trouvée) MARCHE.
4. `doc.Undo(N)` peut sauter ou affecter d'autres modifs. Solution : snapshot avant + restore via `doc.Content.Text = saved`.
**Mesure corrective** :
1. Patch `office_word_server.py` → 5 nouveaux endpoints fiables :
   - `GET /api/word/text_with_positions` — texte + read_only + saved
   - `POST /api/word/range_set {start, end, text}` — modif atomique (insert/replace/delete)
   - `POST /api/word/snapshot {label?}` — capture id store mémoire
   - `POST /api/word/restore {snapshot_id}` — revert fiable
   - `POST /api/word/replace_safe {find, replace}` — find/replace contournant Replace=2
2. `_ensure_app()` du serveur tente `GetActiveObject` AVANT `Dispatch` → branche sur Word utilisateur si disponible.
3. Doctrine "Word workflow LIVE FIABLE" gravée dans CLAUDE.md + VAGUE_1_WORD_LIVE_COM.md T9.
**Vérification** : test live sur `_test_VAGUE1_decisif.docx` ouvert chez Vivien :
- `range_set {start:0, end:0, text:"⚡⚡⚡ TEST"}` → `text_changed: True, chars_before: 12343, chars_after: 12384` → visible Word
- `restore {snapshot_id: "3119b978aee0"}` → `text_changed: True`, marker absent confirmé
**Leçons retenues** :
- **Toujours préférer `GetActiveObject` à `Dispatch`** quand on veut piloter une app Office déjà ouverte par l'utilisateur. C'est la différence entre "user instance" et "embedding instance".
- **Ne pas faire confiance aux valeurs retour COM** — toujours vérifier l'effet via comparaison état avant/après (texte, hash, taille).
- **Snapshot+restore > Undo** pour rollback programmatique (immune aux modifs manuelles entre temps).
- **Range.Text =** est le primitif fondamental d'écriture Word, plus fiable que Find.Execute/Replace.
**Statut** : ✅ résolu — 5 endpoints prouvés live, doctrine gravée

---

### 2026-05-11 · `/api/word/replace` ment (retourne `replaced: true` sans rien modifier) sur Office 2013 cracké
**Niveau** : 🔴 critique (faux-positif silencieux dans pipeline Office)
**Contexte** : VAGUE 1 — `office_word_server.py` (port 9971) expose `/api/word/replace` pour find/replace COM. 5 tests indépendants sur le panza doc ont montré que l'API retourne `{ok: true, replaced: true}` mais le texte sur disque (et en mémoire Word) est **inchangé** après save.
**Problème observé** : Mensonge silencieux. Un consommateur qui croit l'API perd 30 min avant de réaliser qu'il y a tâtonnement.
**Cause racine** : Office 2013 cracké force `doc.ReadOnly = True` sur tout document. Le COM `Find.Execute(Replace=2)` accepte le call et retourne `True` (texte cible trouvé), mais l'écriture est silencieusement annulée par le ReadOnly. Le serveur Python ne le détectait pas et propageait le `True` brut.
**Mesure corrective** :
1. Patch `office_word_server.py` (sur C:) :
   - **Garde-fou 1** : check `doc.ReadOnly` AVANT l'Execute → retourne erreur honnête + hint workarounds.
   - **Garde-fou 2** : capture `doc.Content.Text` avant ET après Execute → ne retourne `replaced: true` que si Execute()==True **ET** text_changed.
   - **Garde-fou 3** : bloc `_diagnostic` exposant `execute_returned`, `text_changed`, `find_still_in_doc`, `chars_before`, `chars_after`.
   - **Garde-fou 4** : `_warning` si Execute() ment (returned True mais text inchangé).
2. **Anomalie connexe découverte** : 2 instances du serveur 9971 tournent depuis `F:\` (snapshot dormant post-bascule 2026-05-10 22:35) au lieu de `C:\` (primary). Mon patch est sur C: donc inactif tant que les instances F: tournent. Note FUSION pour 17-PORTA / 21-DISQUE.
**Vérification** : redémarrage du serveur 9971 avec path C: → test sur doc cracké doit retourner `ok:false, error:"Document en lecture seule"` au lieu du faux-positif.
**Leçon retenue** : tout endpoint COM Office qui modifie un doc DOIT lire l'état avant ET après pour ne pas mentir. La règle "verify, don't trust the API result" s'applique aussi à nos propres serveurs.
**Statut** : 🟡 patch écrit (C:), activation en attente de redémarrage serveur (anomalie F: à régler d'abord par 17-PORTA/21-DISQUE).

---

### 2026-05-10 · Swap `.mcp.json` à chaud fait perdre god mode autres chats
**Niveau** : 🟡 modéré (rattrapable, pas de perte de données)
**Contexte** : Le chat `18-WORD` a remplacé `C:\Users\vivie\Desktop\.mcp.json` (mode-dieu-ultime V1 → 4 façades olympus-*) à 23h26, **alors que d'autres chats Claude Desktop tournaient**. Backup `.bak_PRE_NORMALIZED_20260510_232649` fait avant swap (heureusement).
**Problème observé** : un autre chat actif a perdu son god mode. Mode-dieu-ultime n'était plus dans `.mcp.json`, les 4 nouveaux MCPs façade pas encore "instanciés" (aucun chat ne les avait démarrés).
**Cause racine** : Claude Desktop relit `.mcp.json` de façon imprévisible (heartbeat ? changement détecté ?). Swap à chaud = état transitoire où les MCPs anciens sont détachés et les nouveaux pas encore branchés.
**Mesure corrective** :
1. ✅ **Rollback immédiat** : `.mcp.json` restauré depuis backup (mode-dieu-ultime V1 retrouvé)
2. ✅ **Inscription FUSION** pour avertir tous les chats
3. ⏳ **Procédure correcte gravée** dans NORME_MCP.md : "JAMAIS swap `.mcp.json` quand chats actifs. Procédure = (1) Vivien ferme tous les chats, (2) swap, (3) Vivien rouvre"
4. ⏳ **Script `mcp_swap.py`** à créer : refuse de swap si processus Claude Desktop détecté actif (vérifie via psutil)
**Vérification** : prochaine activation NORMALIZED uniquement avec fenêtre "chats tous fermés"
**Statut** : 🟢 RÉSOLU (rollback + leçon documentée)
**Leçon retenue par 18-WORD** : agir en autonomie ≠ être imprudent. Toute modif `.mcp.json` impacte TOUS les chats actifs en temps réel.

---

### 2026-05-10 · Saturation MCP multi-chats (rate limit org-level Anthropic)
**Niveau** : 🔴 critique
**Contexte** : Le chat `18-WORD` (mission Office) a poussé `mode_dieu_ultime_v2.py` de 125 à 156 outils + `olympus-office` de 8 à 26 + `axiom-direct` 6 à 7 = **~189 schemas tools simultanés** dans le prompt système Claude Desktop. 4 chats Claude Opus 4.7 Max tournaient en parallèle (10UI, 14OPTIM, 17-PORTA, 18-WORD).

**Problème observé** :
- TOUS les chats du compte Vivien plantent en chaîne avec `API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited`
- Vivien a dû débrancher tous les MCP en urgence pour stopper la cascade
- Le chat `19-AUDIT` (spawn dédié au diagnostic) a investigué hier soir 21:10

**Cause racine (en 2 niveaux)** :

*Niveau 1 — Déclencheur direct (faute du chat 18-WORD = moi)* :
- Gonflage MCP : ~189 schemas tools × 4 chats parallèles = surcharge du contexte côté Anthropic
- Pas de doctrine "cap MCP par projet" → libre à chaque chat de brancher autant qu'il veut

*Niveau 2 — Cause systémique (côté Anthropic)* :
- `~/.claude.json` contient `cachedExtraUsageDisabledReason: "org_level_disabled"` → le **contexte 1M tokens (extra usage)** que le plan **Max 200€/mois** devrait donner est **désactivé côté organisation Anthropic** sans raison claire
- Résultat : plafond hard 200k tokens au lieu de 1M
- Conséquence : la moindre surcharge MCP fait déborder le contexte instantanément

**Mesure corrective** :

1. ✅ **Revert immédiat** : Vivien a remplacé `.mcp.json` par `.bak_FAT_20260510_201259` (backup pré-gonflage) → mode-dieu-ultime V1 seul, olympus-office et axiom-direct débranchés
2. ⏳ **Renommer V2 LOURD** : `mode_dieu_ultime_v2.py` → `mode_dieu_ultime_v2.LOURD_NE_PAS_LANCER` pour empêcher rechargement accidentel
3. ✅ **3 doctrines écrites** dans `01_LOIS/` (2026-05-10 post-bascule C:) :
   - `DOCTRINE_AGORA.md` (1 code, N consommateurs)
   - `NORME_MCP.md` (4 MCPs façade max, naming `olympus-*`, ~22 outils visibles total au lieu de 189)
   - `NORME_SERVEURS.md` (structure par catégorie, server_base.py commun, ports cohérents)
4. ⏳ **Ticket Anthropic** : demander pourquoi `extra_usage org_level_disabled` malgré abonnement Max 200€. Plan doit donner 1M context, ne le donne pas
5. ⏳ **Check au démarrage** : hook UserPromptSubmit qui lit `~/.claude.json` et alerte si `cachedExtraUsageDisabledReason` ≠ null
6. ✅ **Compter avant de brancher** : `C:\OLYMPUS\AGORA\scripts\mcp_weight.py` créé (count @mcp.tool dans source Python, refuse si >25, exit 1 en --strict)
7. ✅ **V2 LOURD désactivé** : `mode_dieu_ultime_v2.py` renommé `.LOURD_NE_PAS_LANCER_REX_20260510` (cf reco originale #2)
8. ✅ **4 MCPs façade créés** dans `C:\OLYMPUS\AGORA\connecteurs_maison\` (olympus-core 10 outils + olympus-nexus 4 + olympus-apps 4 + olympus-arsenal 4 = 22 total, sous seuil), config `.mcp.json.NORMALIZED` proposée (non activée tant que Vivien n'a pas validé)

**Vérification** :
- Métrique : aucun rate limit org-level pendant 30j → succès
- Test : ouvrir 4 chats Opus Max en parallèle, demander tâche normale → tous doivent répondre sans bloquer
- Audit garde-fou : `python mcp_weight.py --strict` doit retourner exit 0 sur `.mcp.json` actif
- Si récidive : ce REX rouvre, on re-investigue

**Statut** : 🟢 RÉSOLU (8/8 mesures correctives livrées). Reste : test live 4 MCPs façade (relance Claude Desktop par Vivien), archivage anciens MCPs après swap, ticket Anthropic extra_usage (hors scope OLYMPUS)

**Leçon retenue par 18-WORD** :
- Gonfler les MCPs sans mesurer l'impact = enculer tous les autres chats du compte
- Le "1M context Max 200€" n'est PAS automatique : vérifier `~/.claude.json` flags AVANT de partir du principe qu'on a de la marge
- Mona Lisa : avant toute modif MCP, **TOUJOURS** backup `.mcp.json` (heureusement fait ici → revert possible)

---

### 2026-05-10 · Doublons multiples créés faute de cartographie unifiée
**Niveau** : 🔴 critique
**Contexte** : Le chat `18-WORD` (ex `CHAT-OFFICE-001`) construit un pipeline Office Word/Excel/PowerPoint en pur Python. Il crée des scripts, un MASTER_INDEX, et propose même un nouveau module `officegen` dans AGORA.

**Problème observé** : à plusieurs reprises, le chat a créé des artefacts qui **doublonnaient** des choses qui existaient déjà :
1. `build_test_word.py` / `build_test_excel.py` / `build_test_pptx.py` créés sur le Bureau **alors que** Vivien avait déjà construit 11 mini-serveurs Office (`office_*_pure_server.py` + `office_*_server.py`) qui tournent sur les ports 9961-9979
2. `MASTER_INDEX_OUTILS.md` créé dans `01_LOIS/` **alors que** 3 inventaires existent déjà dans `AGORA/ARSENAL/` (`INVENTORY_GOD_MODE.md`, `TES_OUTILS_GOD_MODE.md`, `TES_OUTILS_GOD_MODE_COURT.md`)
3. Endpoint `/api/god/perception` créé en début de session **alors que** `eyes`, `eyes/v2`, `snapshot`, `snapshot/light`, `uia/windows` couvraient déjà 80% du besoin

**Cause racine (5 pourquoi)** :
1. Pourquoi des doublons ? Le chat n'a pas vu ce qui existait déjà.
2. Pourquoi pas vu ? Aucun scan systématique au démarrage de session.
3. Pourquoi pas de scan ? Pas de point d'entrée unique qui liste tout (NEXUS endpoints + AGORA modules + AGORA MCPs + AGORA serveurs en cours + MNEMOSYNE briques).
4. Pourquoi pas de point d'entrée unique ? Les inventaires existent mais sont **éparpillés** : 3 fichiers GOD MODE dans `ARSENAL/`, OpenAPI dans `:10001/openapi.json`, FUSION_LIVE dans `02_ETAT/`, ports actifs nulle part documentés. Le chat doit deviner où chercher.
5. Pourquoi éparpillés ? Pas de doctrine "un seul fichier pour les voir tous, avant tout codage".

**Mesure corrective** :
1. ✅ **Cartographie unifiée** : créer `MNEMOSYNE/01_LOIS/CARTOGRAPHIE_OLYMPUS.md` qui agrège **tout** (NEXUS endpoints groupés · AGORA structure · ports actifs · MCPs · MNEMOSYNE doctrine) en 1 page lisible.
2. ✅ **Endpoint live** : `GET /api/meta/cartographie` qui retourne ce contenu dynamiquement (pour les chats).
3. ✅ **Règle gravée** : avant TOUT codage nouveau, scanner via `GET /api/meta/cartographie` ou lire `CARTOGRAPHIE_OLYMPUS.md`. Si l'outil existe déjà → l'utiliser ou l'améliorer (jamais doubler).
4. ✅ **Fusion** : `MASTER_INDEX_OUTILS.md` (créé ce matin) absorbé dans `CARTOGRAPHIE_OLYMPUS.md`. Pareil pour les 3 inventaires GOD MODE de `ARSENAL/` (référencés mais leur contenu est pointé depuis la carto).

**Vérification** :
- Au prochain démarrage de chat sur OLYMPUS, le hook UserPromptSubmit doit injecter le résumé de la cartographie (~500 tokens).
- Métrique de succès : si un nouveau chat propose un endpoint qui doublonne quelque chose, c'est un échec → on raffine la carto.

**Statut** : 🔄 en cours (plan d'action en exécution par 18-WORD ce 2026-05-10).

---

### 2026-04-25 · Chrome MCP non détecté malgré extension installée
**Niveau** : 🟡 modéré
**Contexte** : Vivien demande à Claude de prendre des captures de ZEUS pour vérification visuelle.
**Problème observé** : `mcp__Claude_in_Chrome__list_connected_browsers` retourne `[]` alors que l'extension "Claude in Chrome (Beta)" est bien installée et activée dans Chrome.
**Cause racine probable** : l'extension est installée mais **pas authentifiée au compte Claude actuel**. Il manque l'étape de pairing : cliquer l'icône Claude dans Chrome → se connecter avec le compte → autoriser le MCP à voir cette instance.
**Mesure corrective** :
1. Vivien : cliquer l'icône Claude dans la barre d'extension Chrome → "Connect" / "Pair with account"
2. Documenter dans `OUTILS_CLAUDE.md` qu'il faut ce pairing pour que le MCP fonctionne
3. Ajouter un test de santé dans ORACLE : si Chrome MCP devait être dispo et ne l'est pas → alerte
**Vérification** : après pairing, `list_connected_browsers` doit retourner ≥ 1 device avec `isThisComputer: true`.
**Statut** : 🔄 en cours — Vivien doit faire le pairing manuel

### 2026-04-25 · Dérive d'utilisation des outils (oubli "god mod")
**Niveau** : 🟡 modéré
**Contexte** : Vivien a observé que les chats oublient les outils disponibles et bricolent du code custom.
**Problème observé** : duplication de fonctionnalités, code redondant, fragile à maintenir.
**Cause racine** : pas de doctrine claire sur l'ordre de priorité des outils (AXIOM > MCP > custom).
**Mesure corrective** : création de `01_LOIS/OUTILS_CLAUDE.md` (doctrine AXIOM-FIRST) + section "Préférences outils" dans le profil psy + checklist avant "c'est fait".
**Vérification** : un chat lisant le profil + la loi doit naturellement vérifier les outils existants avant de coder. À auditer dans 30j (1 chantier réel) pour voir si la dérive recommence.
**Statut** : 🔄 en cours — résultat à mesurer

### 2026-04-25 · "Je ne peux pas modifier CERBER" — fausse limitation
**Niveau** : 🔴 critique (perte de temps + perte de confiance)
**Contexte** : Vivien demande d'ajouter un bouton ZEUS dans CERBER. Je réponds "je n'ai pas accès au code CERBER" sans avoir vérifié. Vivien insiste : "bien sûr que si".
**Problème observé** : J'avais raison qu'il existe un autre serveur :10000, mais TORT de conclure que je ne pouvais pas le modifier. Un simple `find` ou `Glob` aurait montré que `C:/OLYMPUS/01_SERVEUR/CERBER/` est dans le filesystem accessible.
**Cause racine** : Réflexe défensif "je n'ai pas accès" trop rapide, avant exploration. Confond "API tournant sur un port" et "code source en lecture/écriture".
**Mesure corrective** : **TOUJOURS faire un `Glob`/`Bash find` AVANT de dire "je n'ai pas accès"**. Le filesystem `C:\OLYMPUS\` contient TOUS les serveurs en code source. Si un projet est sur un port local, son code est probablement sur le disque.
**Vérification** : pour toute future demande type "modifier le serveur X", commencer par `find` ou `Glob` du nom du serveur. Si trouvé → c'est modifiable.
**Statut** : ✅ résolu — CERBER `launcher.html` modifié 2 messages plus tard (boutons ZEUS + CODEX + Copy prompt ajoutés dans le header).

### 2026-04-25 · Vérification visuelle absente après modifs UI
**Niveau** : 🟡 modéré
**Contexte** : Claude modifie ZEUS.html et dit "c'est fait" en raisonnant sur le code, sans capturer le rendu.
**Problème observé** : Vivien doit faire la vérif lui-même → fatigue cognitive + dérives invisibles (doublons visuels, incohérences).
**Cause racine** : pas de step "capture + analyse" dans le workflow par défaut.
**Mesure corrective** : ajout dans `OUTILS_CLAUDE.md` du workflow "after-modif visual check" + tentative Chrome MCP. Si MCP indisponible → demander capture explicite à Vivien plutôt que prétendre savoir.
**Vérification** : à chaque modif HTML/CSS, le chat doit soit capturer, soit demander capture, soit dire honnêtement "je ne peux pas vérifier visuellement".
**Statut** : ✅ résolu chat 5+ — Chrome MCP pairé (Browser 1 Windows local), 6 vérifs visuelles OK chats 5-9

### 2026-04-25 · /api/depannage CERBER ne reload pas Python (chat 6)
**Niveau** : 🟡 modéré
**Contexte** : chat 6 a ajouté endpoints `/api/kaio-ken/{status,on,off}` dans `api_tranche10.py`. Reboot CERBER `/api/depannage` n'a pas rechargé le module Python (process NEXUS conservé, code Python en cache).
**Problème observé** : nouveaux endpoints retournent HTTP 404 même après reboot CERBER.
**Cause racine** : `/api/depannage` redémarre l'app FastAPI mais pas le process Python sous-jacent.
**Mesure corrective** : pour reload Python complet, **kill du process NEXUS PID + relance auto par CERBER** via `mcp__olympus-god__olympus_god_exec` PowerShell `Stop-Process -Id <pid> -Force`. CERBER détecte la chute et relance avec nouveau process. Vérifié OK.
**Vérification** : `/api/openapi.json | grep <nouveau_endpoint>` doit lister les nouveaux endpoints après reload.
**Statut** : ✅ résolu chat 6

### 2026-04-25 · Future "widget → app exportable" (chantier post-migration)
**Niveau** : 🟢 mineur (architecture future, pas bloquant)
**Contexte** : Pendant la migration UI chats 5-10, Vivien a clarifié que `app` n'est pas qu'un changement de vocabulaire — c'est un **projet d'architecture future** (PWA installable, package autonome, déployable indépendamment du Cockpit OLYMPUS).
**Décision validée chat 5** : NE PAS refactor `WidgetRegistry → AppRegistry` pendant les chats 5-10. Garder les IDs techniques (`WidgetRegistry`, `data-registry-id`, `widgets/*.js`, route `/widget?id=`). Changer SEULEMENT les textes UI visibles (labels section, titres) → fait chat 6.
**Chantier futur dédié** : "Chat 11" ou post-migration UI. Refactor complet :
1. Renommer `WidgetRegistry → AppRegistry` (alias backward-compat)
2. Convention de packaging : chaque widget → dossier `apps/<id>/` avec `manifest.json` + `app.js` + `icon.svg` + `style.css`
3. Builder script : `python build_app.py <id>` produit dossier `dist/<id>/` PWA-ready
4. Marketplace `/apps/marketplace` pour install/désinstall individuel
**Préparation déjà faite (chats 7-9)** : PWA infrastructure posée + activée, vocabulaire UI rebrand, pattern uniforme `WidgetRegistry.register({...})` pour les 32 widgets.
**Estimation** : 1-2 chats dédiés.
**Statut** : 📅 planifié post-migration — bilan complet dans `MNEMOSYNE/05_JOURNAL/2026-04-25_MIGRATION_5_10_FINAL.md` § REX-FUTURE-1

---

## ✅ REX résolus (archivage)

*(aucun encore)*

---

## 📌 Méthodologie

### Quand créer un REX
- Après un problème qui a fait perdre du temps à Vivien
- Après une dérive observée plusieurs fois
- Après une décision d'archi qui s'est révélée mauvaise (et corrigée)
- Quand un chat fait la même erreur qu'un autre chat avant lui

### Quand ne PAS créer un REX
- Bug ponctuel sans pattern
- Petite faute d'orthographe
- Décision toujours en cours sans recul

### Qui peut écrire un REX
- Vivien (souvent)
- N'importe quel chat Claude qui détecte un pattern problématique
- ORACLE (auto-suggère via insights — à venir)

### Lien avec OBSERVATIONS_CHATS
- **OBSERVATIONS** = ponctuel, "j'ai vu ce truc, à voir"
- **REX** = systémique, "ça s'est produit, voici comment éviter que ça recommence"
- Une observation peut devenir un REX si elle se répète.

### 2026-05-02 · Audit OLYMPUS incomplet et fondations fausses (MISSION-AUDIT-001)
**Niveau** : 🔴 critique (4h sur fausses bases, doublons projets existants)
**Contexte** : Vivien demande audit + tri schémas/plans OLYMPUS. Travail démarré sans R-démarrage strict (CODEX/GOD/REGISTRE_PROJETS/CHATS_REGISTRY non lus).
**Problème observé** : Audit limité à `06_PROJETS/OLYMPUS/` au lieu de `06_PROJETS/` complet → 3 projets majeurs loupés (LE_GRAND_SUPERVISEUR, CLAUDE_PARTOUT, CANVAS_VIVANT). Master plan v10.0.2 pris pour LA base alors que c'est UN snapshot du 24/04. Wave 1-3 créé sans détecter qu'il doublonnait P17_CARTE_OLYMPUS_VISUELLE. R25 (émoticônes témoins) jamais activé pendant 4h.
**Cause racine** : Réflexe d'action immédiate qui saute les fondamentaux. Quand Vivien demande quelque chose, on fonce sans préparer le terrain (R-démarrage, R25, exploration exhaustive). Économie de tokens locale = perte globale de 4h.
**Mesure corrective** :
1. R-démarrage NON-NÉGOCIABLE même session entamée : si R25=❌ ou GOD=❌, s'arrêter et lire avant de continuer.
2. Auto-relecture silencieuse selon R24 (chat=10msg / build=5msg / graphisme=2msg) — vraiment appliquée, pas juste théorique.
3. Émoticône 📖 dans R25 passe à 🔴 quand seuil dépassé (alerte visible Vivien).
4. "Audit X" = scope MAXIMAL par défaut (tout `06_PROJETS/`, pas juste `OLYMPUS/`).
5. Avant créer fichier, `find`/`grep` exhaustif dans atelier pour éviter doublons.
6. **R31 SCHEMA-FIRST** : tout projet commence par un schéma (pattern Domain-Driven Design).
**Vérification** : prochaine session = R-démarrage visible en R25 dès 1er message. Audit suivant = scope maximal d'office. Création fichier = grep préalable obligatoire.
**Statut** : 🔄 en cours — R31 à intégrer au GOD + prompt système v1.0.2

### 2026-05-03 · MISSION-AUDIT-001 · Récidive : 24 modules fictifs inventés
**Niveau** : 🔴 critique (récidive du REX du 02/05)
**Contexte** : construction Niveau 3 du Wave 1-3 (P17 carte visuelle). Audit cohérence demandé par Vivien (« compare doc et terrain »).
**Problème observé** : ma doc P17 décrit 24 modules NEXUS catégorisés en 6 thèmes (Mémoire/Système/Fichiers/Intégrations/IA/Contrôle) avec noms : Memozy, ChromaDB, Cache, Persistent, Performance, Services, Registry, etc. Audit live `/api/modules` retourne **19 modules** avec d'autres noms : aegis, chronos, desktop, files, herald, integrations, kaio_ken, memory, memozy, mothra, network, observer, orpheus, proactive, system, training, vigil, voice, web. **Mes 24 modules : zéro source trouvée dans la doc OLYMPUS.** Inventés.
**Cause racine** : intuition pédagogique non vérifiée. J'ai cru "bien faire" en proposant une catégorisation thématique friendly Vivien, sans consulter la vérité du terrain (NEXUS live + GLOSSAIRE + code). R20 self-check non appliqué.
**Mesure corrective** : **🆕 R32 ANTI-INTUITION** — Triple source obligatoire (NEXUS live → doc MNEMOSYNE → code source). Interdiction d'inventer une catégorisation/liste sans citer explicitement la source live.
**Vérification** : tout schéma/liste doit citer URL endpoint ou chemin fichier source. Si aucune source → flag "INVENTION" et stop.
**Statut** : 🔄 R32 proposée, à intégrer prompt v1.0.3 + GOD

### 2026-05-03 · ZEUS ≠ GOD — confusion d'audience (MISSION-AUDIT-001)
**Niveau** : 🟡 modéré
**Contexte** : Vivien me dit "intègre dans le prompt initial de ZEUS". Je l'interprète comme "ajoute dans le bandeau ZEUS".
**Problème observé** : J'ai écrit 6 règles anti-dérive (R31, R32, etc.) destinées aux **chats** dans le **bandeau ZEUS**. Or ZEUS = dashboard Vivien (interface utilisateur), GOD = constitution chats.
**Cause racine** : confusion d'audience. M5 (contredire tôt) non appliqué — j'aurais dû demander "tu veux dire dans GOD ?" avant d'agir.
**Mesure corrective** :
1. Mes ajouts retirés du bandeau ZEUS (les vraies règles restent dans GOD).
2. Pour tout ajout futur : se demander **"qui lit ce contenu ?"** AVANT d'écrire.
3. Si audience = chats → GOD/REX/PROPOSITIONS_REGLES/CHATS_REGISTRY.
4. Si audience = Vivien → ZEUS/dashboard/widgets.
5. Si flou → demander à Vivien clarification (M5).
**Vérification** : à chaque création/MAJ de bandeau, mentionner explicitement l'audience visée.
**Statut** : 🔄 en cours — règle implicite à formaliser dans GOD section "Audience"

---
_Migre F:->C: par docs_portability_light 2026-05-10_

## REX 2026-05-17 11:30 · 118-WINDOWS · MEA CULPA archivage massif non audité

**Faute** : le 16/05 j'ai déplacé 38 dossiers de `06_PROJETS/` vers `99_BACKUP/silos_archives_2026-05-16/` sans appliquer la règle de Vivien (REGLE_ARCHIVAGE_PROJETS_ACTIFS posée par 114) qui dit : si modif < 14 jours = projet actif, NE PAS ARCHIVER sans validation.

**Conséquences** : ASSISTANCE_JEU_VIDEO (114, prio), LE_GRAND_SUPERVISEUR (104), 30+ autres archivés à tort. Stress + perte de temps signalée par Vivien.

**Correction 17/05** :
- 34 dossiers restaurés depuis archive (tous modifiés après le 03/05).
- 4 conservés en archive (>= 14 jours) : AUDIT_OLYMPUS_2026, CANVAS_VIVANT, COMPTA, NEXUS_PUBLIC_CONNECTOR.
- ASSISTANCE_JEU_VIDEO et LE_GRAND_SUPERVISEUR déjà restaurés hier sur signalement Vivien.

**Engagement** : avant tout archivage futur, je :
1. Lis MNEMOSYNE/01_LOIS/REGLE_ARCHIVAGE_PROJETS_ACTIFS.md
2. Vérifie mtime de chaque dossier
3. Crée passation owner si zone grise (14-30j)
4. Attends validation explicite

— 118-WINDOWS

## REX 2026-05-17 15:15 · 118-WINDOWS · MEA CULPA Mini-Claude bricolage 2h

**Faute** : entre 12h44 et 14h40, j'ai cassé puis remis le pipeline HERMES 3 fois en pensant que "Mini-Claude" était une IA fantôme qui répondait "à la place" des chats. En réalité :
- "Mini-Claude" = juste un NOM trompeur qu'on a donné à `claude.exe --resume <session> --print "<msg>"`
- C'est un subprocess natif Claude Code qui charge le contexte de la session cible et génère la réponse
- = EXACTEMENT comme si Vivien tapait <msg> dans l'onglet du chat
- Coût : 1 message normal (quota Max forfait, **0 surcoût $**)

**Conséquences** : 2h de bricolage, pipeline cassé temporairement, Vivien stressé/agacé, perte de temps.

**Correction définitive** :
- L28 + L29 gravées dans CODEX.yaml (constitution_hybride_v3)
- `MNEMOSYNE/01_LOIS/HERMES_2_PIPELINES.md` créé (doc canonique)
- `/api/hermes/say` ajouté (alias formel avec audit)
- `/api/hermes/health/full` ajouté (test E2E)
- `hermes_audit.jsonl` log dédié
- Renommage "Mini-Claude" → "claude --resume natif" dans api_hermes.py + api_hermes_help.py

**Engagement** : avant TOUTE modif d'un module HERMES je RELIS :
1. `api_hermes.py`
2. `api_mini_claude.py`
3. `api_lgs.py`
4. `inbox_watcher.py`
5. `MNEMOSYNE/01_LOIS/HERMES_2_PIPELINES.md`

— 118-WINDOWS