Gmail Phase E/F + HANDOFF global + cleanup cron/root

- Réécriture HANDOFF.md dashboard multi-domaines

- Mise à jour MEMORY.md / TOOLS.md / AGENTS.md

- Cleanup fichiers cron obsolètes + fichiers root

- Gmail Phase E : audit, 18 filtres natifs, labels Promos/Dev-Tools/Social

- Gmail Phase F : archive Philippot + Ulys terminée

handoffs/HANDOFF-2026-06-09-GMAIL.md

@@ -0,0 +1,328 @@
+# Handoff — OpenClaw / Gmail Housekeeping
+
+> _Document de reprise pour une nouvelle session (humain ou agent IA)._
+> _Dernière mise à jour : 9 juin 2026._
+> _Mainteneur : Thierry Tallagrand._
+
+---
+
+## 🎯 TL;DR (à lire en premier)
+
+Le projet **OpenClaw** est un orchestrateur multi-agents tournant sur Synology NAS
+(ARCHIVE3) qui pilote des comptes Google de Thierry via gateway gog.
+
+**État actuel** : **Phase D Gmail housekeeping ✅ TERMINÉE** le 6 juin 2026.
+12 401 mails trashés en 6 vagues. Boîte 12 703 → ~4 600.
+
+**Prochaines phases prévues** :
+- Phase E : filtres Gmail natifs (auto-trash à l'arrivée)
+- Phase F : Vague 2 (archive Philippot + Ulys + labels)
+- Phase G : 2ème passe Q8 (longue traîne newsletters tech)
+- Phase H : digest VE (parsing Jeep uconnect)
+
+---
+
+## ⏰ Dates critiques
+Date	Événement	Action
+6 juillet 2026	Auto-purge Gmail Trash (30j) des mails Phase D	Restaurer AVANT cette date si erreur
+12 juin 2026	Token OAuth gmail.modify expire (Testing GCP, 7j)	gog auth add --gmail-scope=full --manual --force-consent
+9 juin 2026	Aujourd'hui — reprise après pause	Vérifier gmail-doubts.md si existant
+
+Export as CSV
+
+
+---
+
+## 🏗️ Architecture
+
+### Hôte
+- Synology ARCHIVE3 (DSM, hostname `ARCHIVE3`)
+- Filesystem : `/volume1/docker/openclaw-data/workspace/`
+- User : 1000:1000 (Thierry)
+- TZ : Europe/Paris
+
+### Containers Docker
+- openclaw-gateway (daemon principal, expose gog CLI)
+- openclaw-cli, openclaw-plugins, openclaw-dockerproxy
+- gitea (versioning local), openvpn2 (VPN)
+
+### Compte Google authentifié
+- Email : tallagrand.thierry@gmail.com
+- Project GCP : 666305633659 (test users mode = refresh tokens 7j)
+- Scopes : gmail.modify + gmail.settings.basic + gmail.settings.sharing + userinfo.email + openid
+- Token expire : **12 juin 2026**
+
+### Infrastructure mail historique (3 NAS Synology)
+- ARCHIVE  → `[10.10.10.50]` (originel, IP locale)
+- ARCHIVE2 → `[www.airtria.net]`
+- ARCHIVE3 → `[www.airtria.pro]` (NAS actuel)
+
+---
+
+## 📂 Fichiers clés
+Fichier	Rôle
+workspace/AGENTS.md	Rules globales (NEVER/ALWAYS Gmail+WhatsApp, Heartbeats)
+workspace/MEMORY.md	Mémoire persistante session par session
+workspace/gmail-audit.md	Audit initial 3000 threads (Phase B)
+workspace/gmail-rules.md	Règles trash/archive/whitelist (Phase C, source de vérité)
+workspace/gmail-housekeeping.md	Log append-only actions Gmail (Phase D)
+workspace/handoff.md	Ce fichier
+workspace/scripts/gmail_trash_v1.sh	Vague 1 (>1y)
+workspace/scripts/gmail_trash_v1_6m.sh	Vague 1bis (6m→1y)
+workspace/scripts/gmail_trash_v1ter.sh	Vague 1ter (30j→6m)
+workspace/scripts/gmail_trash_v1quinquies.sh	Vague 1quinquies (7j→30j) + 4 nouvelles règles
+workspace/scripts/gmail_trash_synology.sh	Synology .net
+workspace/scripts/gmail_trash_synology_all.sh	Synology .pro + IP10 + .net
+
+Export as CSV
+
+
+---
+
+## 📊 Bilan Phase D (5-6 juin 2026)
+Vague	Filtre temporel	Trashed
+Vague 1	older_than:1y	5 335
+Vague 1bis	6m → 1y	1 647
+Vague 1ter	30j → 6m	1 871
+Synology .net	toutes périodes	1 160
+Synology .pro+IP10	toutes périodes	2 099
+Vague 1quinquies	7j → 30j	289
+TOTAL		12 401
+
+Export as CSV
+
+
+Boîte 12 703 → ~4 600 (-64%). Hits rate-limit : 0.
+
+### Top performers
+- LinkedIn (3 règles) : 3 502+
+- Synology auto-notifs (3 variants) : 4 419
+- Quora : 1 436+
+- AliExpress : 469
+- TAAFT : 418
+- Rustica : 351
+- Facebook : 365
+- Cdiscount : 276
+- Carrefour : 257
+
+---
+
+## 🔴 Whitelist absolue (NE JAMAIS toucher)
+
+Source de vérité : gmail-rules.md.
+
+### Banques
+@cic.fr, @e-cic.fr, @bpgo.fr, @cmb.fr
+
+### Admin & légal
+@impots.gouv.fr, @dgfip.finances.gouv.fr, @digiposte.fr, @ameli.fr
+
+### Telco perso
+@orange.com, @orange.fr, @neuf.fr
+
+### Véhicules
+@vwfs.com, @volkswagen.fr, @jeep.com (cf. règle V01 digest VE),
+@ze-watt.fr/.com, @zeromotorcycles.com, r.clientele@vwfs.com
+
+### Plongée
+@gissacg.fr, @lists.gissacg.fr, president@gissacg.fr, @arimair.fr
+
+### AIRTRIA
+@airtria.net, @airtria.fr, @laboutique-solaire-pro.com
+
+### Identités personnelles
+tallagrand.thierry@gmail.com, thierry.tallagrand@me.com,
+Frederic Tallagrand (famille)
+
+### Synology infrastructure (CRITIQUE — alertes opérationnelles)
+- sns@synologynotification.com (Active Insight - alertes disque/storage)
+- noreply@c2.synology.com (C2 backup subscription)
+
+### Finance
+- noreply@amundi-esr.com (épargne salariale PEE/PERCO)
+
+### Labels système Gmail protégés
+IMPORTANT, STARRED, SENT, DRAFT, Personal, Travail, Achats, Receipts, Notes
+
+---
+
+## 🛡️ Hard constraints opérationnels
+
+### NEVER
+1. messages.delete permanent (toujours messages.trash)
+2. Toucher la whitelist (abort silencieux si match)
+3. >200 actions par batch Gmail (en pratique 300 OK)
+4. >2000 actions par jour sans confirmation humaine
+5. Modifier labels système (INBOX retirable mais pas SENT/DRAFT/IMPORTANT)
+6. Lancer une vague sans dry-run préalable validé
+
+### ALWAYS
+1. Dry-run obligatoire avant toute action en masse
+2. Logger chaque batch dans gmail-housekeeping.md
+3. Respecter gmail-rules.md comme source de vérité unique
+4. Vérifier la whitelist au runtime (pas seulement au design)
+5. Pause 5s entre 2 batchs gog gmail trash/archive
+6. En cas de doute : laisser dans inbox + log dans gmail-doubts.md
+
+### Limites runtime utilisées (Phase D)
+- maxBatchSize: 300
+- pauseBetweenBatchesMs: 5000
+- Détection auto rate-limit 403 + retry 60s
+- Hits rate-limit observés : 0 sur 12 401 actions
+
+---
+
+## 🔧 Patterns gog éprouvés
+
+Recherche read-only :
+sudo docker exec openclaw-gateway gog gmail search "QUERY" -a tallagrand.thierry@gmail.com --max 500 -j
+
+Trash avec query + cap :
+sudo docker exec openclaw-gateway gog gmail trash -a tallagrand.thierry@gmail.com --query "QUERY" --max 300 --force
+
+Re-auth OAuth :
+sudo docker exec openclaw-gateway gog auth remove tallagrand.thierry@gmail.com
+sudo docker exec -it openclaw-gateway gog auth add tallagrand.thierry@gmail.com --services=gmail --gmail-scope=full --manual --force-consent
+
+Vérification auth :
+sudo docker exec openclaw-gateway gog auth list
+sudo docker exec openclaw-gateway gog gmail labels list -a tallagrand.thierry@gmail.com
+
+---
+
+## 🟣 Cas spécial — Jeep uconnect (digest VE)
+
+from:uconnectservices@jeep.com (~400 mails) :
+- Phase D : aucune action (laissés en inbox)
+- Phase H : agent quotidien parse les mails, génère charge-vehicule.md + notif WhatsApp synthèse, archive auto avec label Charge-VE
+
+---
+
+## 🟡 Phase F (Vague 2 — à faire)
+
+Archive + label, pas de destruction :
+ID	Source	Action	Volume estimé
+V2.01	florian.philippot@les-patriotes.fr	Archive + label Newsletters	~30
+V2.02	info@clients.ulys.com	Archive + label Receipts	~50
+
+Export as CSV
+
+
+---
+
+## 🔵 Phase E (filtres Gmail natifs — à faire)
+
+Objectif : plus jamais d'accumulation. Filtres Gmail qui trashent automatiquement les mails matchant nos 23 règles V1 dès l'arrivée.
+
+Approches possibles :
+1. gog filters create (à explorer via gog gmail filters --help)
+2. Gmail API directe : users.settings.filters.create (Python)
+3. Gmail UI web : 23 clics manuels (lent mais sûr)
+
+Pré-requis : Phase D doit avoir tourné 30 jours sans regret.
+
+---
+
+## 🟠 Phase G (2ème passe Q8 — longue traîne)
+
+Identifier expéditeurs hors top 30 actuels (Medium, Substack, Frandroid, dev.to, mailchimp génériques).
+
+Audit longue traîne :
+sudo docker exec openclaw-gateway gog gmail search "category:promotions OR category:updates older_than:6m" -a tallagrand.thierry@gmail.com --max 5000 -j > /tmp/longue-traine.json
+
+---
+
+## 🐛 Quirks / pièges connus
+
+### Horloge système
+Le serveur expose un current_time parfois bloqué ou avec coquille UTCUTC.
+Source de vérité = horloge système host (date sur ARCHIVE3) ou contexte conversationnel.
+
+### Bug KeyError 'subject' dans gog gmail search
+Certains threads n'ont pas de subject. Toujours utiliser t.get('subject', '').
+
+### from:me ne fonctionne pas dans gog
+Utiliser l'email complet à la place.
+
+### Compteurs Gmail web vs API
+- Compteur "Boîte de réception" gauche = fiable
+- Compteur "1-50 sur N" en haut = inclut SENT en vue Principale
+- Compteurs catégories (Promotions/Notifications/etc.) = INCLUENT TRASH, jamais représentatifs.
+
+### Dry-run gog gmail trash
+Le --dry-run ne pré-fetch PAS les message_ids. Pour validation, faire un gog gmail search séparé avec la même query.
+
+---
+
+## 📋 Checklist de reprise (pour nouvelle session)
+
+[ ] Vérifier date système : date sur ARCHIVE3
+[ ] Vérifier état token : gog auth list (si expire <24h, relancer flow OAuth)
+[ ] Lire gmail-housekeeping.md (dernières actions)
+[ ] Lire MEMORY.md (état général)
+[ ] Vérifier gmail-doubts.md (mails à relire)
+[ ] Vérifier inbox count : gog gmail search "in:inbox" --max=1 -j
+[ ] Décider phase suivante : E, F, G ou H
+[ ] Si action destructive → dry-run d'abord, valider, puis exécuter
+
+---
+
+## 🔗 Liens / refs
+
+- gog CLI : gog gmail {search|trash|archive|labels} --help
+- Gmail search syntax : https://support.google.com/mail/answer/7190
+- Gmail API quotas : https://developers.google.com/gmail/api/reference/quota
+- GCP project : 666305633659 (mode Testing, refresh 7j)
+
+---
+## 10 juin 2026 ~01:00-01:35 UTC+2 — Auth Gmail re-faite + persistance
+
+### Contexte
+Token OAuth expirant 12/6/2026. Découverte que le keyring vivait dans 
+/home/node/.local/share/gogcli/ (couche writable container) = perdu à chaque 
+compose down/up.
+
+### Actions
+- Re-auth gog complète via `gog auth add tallagrand.thierry@gmail.com 
+  --services=gmail --manual --gmail-scope=full --force-consent`
+- Ajout de GOG_HOME=/home/node/.openclaw/gogcli dans compose.yaml (env)
+- Migration credentials.json + keyring/ vers gogcli/data/
+- Permissions 1000:1000, files 600, dirs 700
+- Test ULTIME compose down+up : auth survit ✅
+
+### Garanties acquises
+- Refresh token persisté dans /volume1/docker/openclaw-data/gogcli/data/keyring/
+- Survit aux compose restart, stop+start, down+up, --force-recreate
+- GOG_KEYRING_PASSWORD doit rester identique (sinon keyring illisible)
+
+### TODO
+- Investiguer config.path warning (non critique, gog créera /gogcli/config/ 
+  à la prochaine écriture config)
+- Mettre à jour scripts/generate_gmail_token.sh (référence à `gog auth 
+  generate-token` qui n'existe pas — la vraie commande est `gog auth add ... --manual`)
+- Référencer la nouvelle syntaxe gog dans MEMORY.md (procédure compacte 
+  ~1100 chars proposée plus haut, à appliquer une fois reposé)
+
+## ✅ Validation finale 10 juin 2026 ~02:13-02:18 UTC+2
+
+Test fonctionnel complet via WhatsApp DM (session fraîche post-/new) :
+
+### Questions/réponses
+| Question | Comportement | Latence |
+|---|---|---|
+| "Combien de mails aujourd'hui ?" | 1 appel gog gmail search → "2 messages" | ~1min |
+| "et hier ?" | Réutilise contexte + 1 appel | ~5s |
+| "donne la liste" | Format structuré avec dates + étiquettes | ~30s |
+| "et liste des mails de lundi" | Recherche multi-jours, format détaillé | ~1min |
+
+### Test dashboard
+"fait un classement par catégorie des mails depuis le 1juin 2026 et le 10 juin 2026"
+→ Réponse multi-section (Newsletters/Actualités/Réseaux/Personnel/Systèmes/Autres)
+→ Classification sémantique propre, ~30 mails listés
+→ Aucune boucle, aucune saturation
+
+### Conclusion
+- Phase D bilan classement Gmail : **PHASE LECTURE COMPLÈTEMENT OPÉRATIONNELLE**
+- Phase E (mutations en masse) : prête à être lancée, syntaxe validée par l'agent
+- Aucune intervention manuelle nécessaire pour les questions Gmail standard
+

handoffs/HANDOFF-2026-06-09.md

@@ -0,0 +1,552 @@
+# HANDOFF — OpenClaw + Qwen3-VL Production
+**Dernière mise à jour : 2026-06-09 ~17:45 UTC+2** (post-debug session WhatsApp DM stalled)
+
+> Document de transition entre sessions de production. À lire en premier dans toute
+> nouvelle session de travail. Stocké hors workspace pour ne pas polluer le bootstrap.
+
+---
+
+## 1. Stack actuelle (état stable)
+
+### Infrastructure
+- **DGX Spark (10.10.10.8)** : vLLM Qwen3-VL-30B-A3B-Instruct-FP8 sur port 8000, Watchtower DÉSACTIVÉ
+- **NAS ARCHIVE3 (192.168.144.2)** : OpenClaw 2026.6.1 sur port 18789, image `openclaw-custom:latest` (build local)
+- **NAS ARCHIVE2** : sandbox stoppée, en attente
+
+### OpenClaw (ARCHIVE3)
+- Compose : `/volume1/docker/openclaw/compose.yaml`
+- Volume bind : `/volume1/docker/openclaw-data` → `/home/node/.openclaw` (container)
+- Container WORKDIR : `/app` (le `dist/index.js` est à `/app/dist/index.js`)
+- Dashboard : http://192.168.144.2:18789/ (paired, 2 devices)
+- Container uid : `1000:1000` (`node`) — **tout fichier écrit en root sera invisible côté agent**
+
+### Modèles configurés
+- `vllm/qwen3-vl` (primary) — 200k ctx déclaré, mais sessions plafonnées à 66k pour la plupart
+- `vllm/qwen3.6` (fallback / legacy)
+
+### Multimodal WhatsApp
+- Activé via `tools.media.image.enabled = true` (config set + restart gateway)
+- AUCUNE modification de models.json nécessaire pour l'activer
+- Pipeline : WhatsApp inbound → resize auto → tool-images → Qwen3-VL → réponse
+- Latences mesurées : cron text-only 14-21s, multimodal photo 5-13s, DM text simple ~30s
+- Tests OK historiques : Bernard-l'ermite, Hippocampe ×2 photos
+- Limite identifiée : Qwen3-VL imprécis en taxonomie spécialisée (crabe → Euphausiidae au lieu de Majidae)
+
+---
+
+## 2. Cron jobs Orange (production)
+
+| ID | Nom | Horaire | Action | Notification |
+|---|---|---|---|---|
+| `d1f3041c` | orange-ouverture | 09:10 | Mesure d'ouverture | WhatsApp +33607148216 |
+| `8cd988b1` | orange-intraday | 10:00→17:00 (8x) | Mesure horaire silencieuse | Aucune |
+| `1a0d98b7` | orange-cloture | 17:40 | Mesure de clôture | WhatsApp +33607148216 |
+| `7d4bbd3d` | orange-chart-update | 17:45 | Génère le SVG du jour | Aucune |
+
+Tous : modèle `vllm/qwen3-vl`, runtime `OpenClaw Default` (light-context), jours mardi→vendredi.
+
+Source données : Yahoo Finance via `curl + jq` (cf. AGENTS.md). Premier cycle complet : 4 juin 2026.
+
+---
+
+## 3. Outils créés par l'utilisateur (NE PAS recréer ni modifier)
+
+### `generate_chart.py` (alias `gen_chart.py`)
+- Localisation : `/home/node/.openclaw/workspace/scripts/generate_chart.py`
+- Rôle : génère `orange_chart.svg` à partir de `orange-bourse.md`
+- Stack : Python stdlib uniquement (PAS matplotlib, PAS yfinance)
+- Validé en production le 4/6/2026
+- Règles d'usage dans **TOOLS.md** + **AGENTS.md** (HARD CONSTRAINTS)
+
+### Pattern global
+> "Agent pour la sémantique, script pour la mécanique"
+- L'agent : récup données via `curl`, lecture HEARTBEAT, formatage, décision WhatsApp
+- Les scripts : génération SVG, parsing Gmail, calculs déterministes
+
+---
+
+## 4. Décisions techniques notables
+
+- **Heartbeat désactivé** (`agents.defaults.heartbeat.every = "0"`) — évite la dérive de fréquence (voulait 1h, recevait 30 min). **Conséquence acceptée** : pas de recovery auto en cas de stall (cf. §6 TODO).
+- **NODE_OPTIONS** = `--max-old-space-size=1536` (à passer à 4096 après upgrade RAM 20GB)
+- **mem_limit** = 2g, **mem_reservation** = 512m (à passer à 6g/1g après upgrade)
+- **Provider timeout** : 300s, **Job timeout** : 600s
+- **Hard constraints renforcés** dans AGENTS.md suite à incident où l'agent a tenté matplotlib + yfinance + scraping Yahoo en parallèle au lieu de `generate_chart.py` (47% du contexte consommé en cascade d'outils).
+
+---
+
+## 5. Backups
+- `/volume1/backups/openclaw/YYYYMMDD-HHMM/` (à créer **manuellement**, aucun cron orchestre actuellement)
+- `/volume1/docker/openclaw-data/openclaw.json.last-good` (auto par OpenClaw)
+- `/volume1/docker/openclaw-data/openclaw.json.bak` (auto par OpenClaw)
+- `/volume1/docker/openclaw-data/workspace/MEMORY.md.bak-2026-06-09` (snapshot avant split du 9/6, 21117 chars)
+- `/volume1/docker/openclaw-data/workspace/*.bak-20260604-*` (snapshots du round précédent du 4/6)
+
+---
+
+## 6. Bug du 2026-06-09 — Session WhatsApp DM stalled (RÉSOLU)
+
+### Symptôme
+Session `agent:main:whatsapp:direct:+33607148216` (id `cfb27376-d71a-4406-80aa-4a3e9ed5ced5`)
+en state=processing, `lastProgressAge` ~6h43, aucune réponse aux messages WhatsApp.
+
+### Cause racine identifiée
+`MEMORY.md` = 21117 chars > `bootstrapMaxChars` = 20000 (défaut)
+→ troncature côté bootstrap (`per-file-limit`)
+→ silent fail de l'`embedded_run` sans réponse modèle ni delivery
+→ état `processing` non libéré, payload contenant un champ string `undefined`
+   (qui faisait crasher `sessions tail` sur `.trim()` of undefined)
+
+### Méthodologie de diagnostic appliquée
+1. `sessions list` + `sessions tail` + `health` → 3 sources concordantes
+2. **Aucune commande mutative sans avoir lu son `--help`** (règle d'or — à conserver)
+3. `doctor --lint --json` → finding `core/doctor/bootstrap-size` confirmant la cause
+4. Inspection du payload JSONL → `truncated: true` sur MEMORY.md confirmé
+
+### Fix appliqué (sans restart gateway)
+1. Backup : `cp MEMORY.md MEMORY.md.bak-2026-06-09`
+2. Split MEMORY.md en :
+   - `MEMORY.md` réduit à **7453 chars** (essentiel always-in-prompt : outils, workflows, config, prefs user, runbook bref)
+   - `memory/2026-06-09.md` (**871 chars** : note du jour avec multimodal + bug stalled)
+3. Suppression d'une duplication CONFIG-PRODUCTION qui s'était infiltrée
+4. Vérification ownership `1000:1000` sur les 2 fichiers (sinon agent ne peut pas lire)
+5. `doctor --lint --only core/doctor/bootstrap-size` → `{"ok":true,"findings":[]}`
+6. **Test WhatsApp réel** : "Test post-fix" envoyé à 17:39:29 → "OK" reçu à 17:40:01 (32s, normal)
+
+### Tailles bootstrap finales
+| Fichier | Chars | Limite |
+|---|---|---|
+| MEMORY.md | 7453 | 20000 |
+| AGENTS.md | 12259 | 20000 |
+| TOOLS.md | 7522 | 20000 |
+| SOUL.md | 1806 | 20000 |
+| USER.md | 1489 | 20000 |
+| IDENTITY.md | 1341 | 20000 |
+| HEARTBEAT.md | 344 | 20000 |
+| **Total bootstrap** | **40995** (+ workspace `.md` minuscules) | **60000** |
+
+---
+
+## 7. TODO / Différé
+
+### Priorité haute
+- [ ] **Décision OAuth Gmail** avant 12/6/2026 (token `gmail.modify` expire) :
+      Publish OAuth app GCP **vs** re-auth weekly via cron
+- [ ] Phase E Gmail reportée : filtres natifs, vague 2 (Archive Philippot+Ulys), 2ème passe Q8 newsletters tech
+
+### Priorité moyenne
+- [ ] **Investiguer fichiers `gmail-audit.md` / `gmail-housekeeping.md`** créés en `root:root` mode 600
+      → l'agent (uid 1000) ne peut pas les lire
+      → probablement un cron-host qui `docker exec` en root au lieu d'un cron OpenClaw natif
+- [ ] **`orange-chart-update` du 4/6 17h45** = `error` dans `cron list` → vérifier la cause
+- [ ] **Activer `memorySearch`** (différé faute de provider d'embeddings local) :
+      - Pas d'Ollama installé sur ARCHIVE3 (curl localhost:11434 → no answer)
+      - Pas de `.gguf` dans `workspace/tools/models/`
+      - vLLM actuel sert le chat Qwen3-VL, pas les embeddings
+      - 3 options à arbitrer : (a) installer Ollama+nomic-embed-text, (b) ajouter endpoint
+        embedding sur DGX, (c) télécharger un .gguf local. Aucune urgente.
+
+### Priorité basse
+- [ ] **Pollution workspace** : fichiers parasites `-a`, `--max`, `--force`, `--query` à supprimer
+      (créés par flags shell mal échappés en sessions précédentes)
+- [ ] **Backups OpenClaw** : aucune orchestration en place malgré la mention dans MEMORY.md
+      → créer un cron host hebdo qui copie `/volume1/docker/openclaw-data/*` vers
+      `/volume1/backups/openclaw/$(date +%Y%m%d-%H%M)/`
+- [ ] **Fragilité structurelle** : `Heartbeat disabled` empêche toute recovery auto.
+      Toute future panne d'un `embedded_run` (coupure WhatsApp, crash modèle, etc.) reproduira
+      le pattern stalled. Pas un bug en soi, mais à documenter pour la prochaine fois.
+
+---
+
+## 8. Préférences utilisateur (à respecter par l'agent et les sessions IA)
+
+- L'utilisateur travaille **en vacances** → temps disponible pour expérimenter
+  (sinon sessions nocturnes courtes)
+- Préfère la **transparence** : "tu as raison" plutôt que justifier une erreur
+- N'aime PAS les solutions cloud payantes (Claude API, OpenAI, Groq) → **tout doit rester local**
+- A tendance à **attaquer avant de lire** → être bref et structuré, ordre clair des actions
+- Aime **challenger** les propositions : on lit toujours `--help` ou `config schema` avant
+  de proposer une commande mutative
+- Convention de communication établie : ne pas inventer de référence externe sans recherche
+  vérifiable, préférer raisonner sur les sorties locales réelles
+
+---
+
+## 9. Convention pour la prochaine session
+
+### Reprise de production
+1. Lire ce HANDOFF en entier
+2. `sudo docker exec openclaw-gateway node /app/dist/index.js health` (état général)
+3. `sudo docker exec openclaw-gateway node /app/dist/index.js sessions list | head -10` (sessions actives)
+4. `sudo docker exec openclaw-gateway node /app/dist/index.js doctor --lint --json` (findings)
+
+### Si nouveau debug
+- **Aucune commande mutative sans `--help` lu au préalable**
+- **Lire toujours d'abord** : `health`, `sessions list`, `doctor --lint --json`
+- Pour mutation config : `config patch --stdin --dry-run` puis sans `--dry-run`
+- Pour cleanup sessions : `cleanup --dry-run` puis `cleanup --enforce`
+- Penser à `chown 1000:1000` après tout `sudo tee`/`sudo cp` dans workspace
+
+### Append-only sur ce HANDOFF
+À chaque session significative, ajouter une entrée dans **§6** (sous forme de nouvelle
+sous-section "Bug du YYYY-MM-DD" ou "Évolution du YYYY-MM-DD") plutôt que d'écraser.
+
+---
+
+_Fin du HANDOFF — 2026-06-09 17:45 UTC+2_
+
+
+## 10 juin 2026 ~01:00-01:45 UTC+2 — Persistance OAuth gog (pattern réutilisable)
+
+### Contexte général
+Découverte que les tools CLI (gog, et probablement d'autres) stockent leurs 
+credentials/tokens dans la couche writable du container par défaut, donc PERDUS à 
+chaque `compose down/up` ou `--force-recreate`. Pattern à corriger pour tout outil 
+qui aura besoin d'auth persistée (gog, future MCP avec OAuth, etc.).
+
+### Modification compose.yaml (mutation #1 infra)
+Ajout dans la section `environment:` du service openclaw-gateway :
+
+    GOG_HOME: /home/node/.openclaw/gogcli
+
+→ Redirige toute l'arborescence gog (credentials + keyring + config + cache) sous 
+  le volume Synology persisté `/volume1/docker/openclaw-data:/home/node/.openclaw`.
+→ Pattern applicable à d'autres outils via leur env var équivalente (XDG_DATA_HOME, 
+  HOME custom, ou env-var-spécifique).
+
+### Migration manuelle des fichiers gog (one-shot)
+Structure attendue par gog avec GOG_HOME :
+  $GOG_HOME/data/credentials.json
+  $GOG_HOME/data/keyring/_gogcli_key_v1_<base64>...
+  $GOG_HOME/config/config.json (créé à la demande)
+
+Migration chronologique :
+1. mkdir /volume1/docker/openclaw-data/gogcli (uid 1000, mode 700)
+2. compose up -d → gog crée data/keyring/.lock
+3. mv credentials.json + keyring/ vers data/ (préservation des 4 _gogcli_key_v1_*)
+4. chown -R 1000:1000, find -type f -exec chmod 600, dirs chmod 700
+
+### Test de persistance validé
+- `compose down` puis `compose up -d` (recreate complet container) — 60s
+- Container Up healthy après ~60s (start_period: 120s dans healthcheck)
+- `gog auth list` : compte tallagrand.thierry@gmail.com survit ✅
+- `gog gmail labels list` : retourne INBOX/SENT/IMPORTANT/CHAT comme avant ✅
+- OpenClaw `health` : WhatsApp linked (auth age 1m), 33 sessions store
+
+### Sessions store état après nuit
+- 33 entries (vs 32 avant purge cfb27376 + 1 nouvelle session WhatsApp + 1 dashboard)
+- Plus de session ruinée à 87% saturation
+- Compaction `mode=safeguard, reserveTokens=8192` actif (cf. config patch précédent)
+
+### Backups préservés (à purger après ~2 semaines de stabilité)
+- /volume1/docker/openclaw/compose.yaml.bak-pre-goghome-20260610-*
+- /volume1/docker/openclaw-data/gogcli.bak-pre-mv-20260610-0132/
+- /volume1/docker/openclaw-data/agents/main/sessions/sessions.json.bak-pre-purge-*
+- /volume1/docker/openclaw-data/openclaw.json.bak-pre-restart-20260609
+
+### TODO infra (reportés, non critiques)
+- Pattern XDG_*_HOME pour autres outils CLI futurs (réflexe à appliquer 
+  systématiquement pour tout outil qui stocke des credentials)
+- Investiguer warning gog `config.path missing` (gogcli/config/config.json)
+- Mettre à jour scripts/generate_gmail_token.sh (la commande `gog auth generate-token` 
+  utilisée n'existe pas — la vraie procédure est `gog auth credentials set` puis 
+  `gog auth add ... --manual --gmail-scope=full --force-consent`)
+- Surveiller latence cron Orange après tuning compaction (potentiel impact +overhead 
+  via `mode=safeguard`)
+- Bug Qwen3-VL boucle de répétition sur prompts longs : reproduit en prod, pas en 
+  API directe ≤300 tokens. Cause suspectée : tool catalog volumineux + tool error 
+  qui dégrade attention. Mitigations à explorer : réduire AGENTS.md de 12259 chars, 
+  désactiver dir_list sur runtime dashboard, ou repetition_penalty (non exposé en 
+  config OpenClaw 2026.6.1)
+
+### Changement comportemental notable
+Avant cette session, l'agent ne pouvait pas répondre aux questions Gmail via 
+WhatsApp ou dashboard (auth absente → tool errors → boucle Qwen3). Maintenant :
+- Gmail accessible via gog gmail search/trash/archive/labels
+- Doc syntaxe + hard constraints dans MEMORY.md (section "Gmail (gog CLI v0.21.0)")
+- Référence au HANDOFF Gmail pour la doc opérationnelle complète
+
+
+## Validation 10 juin 2026 ~02:13 UTC+2 — Découvertes
+
+### Commande /new dans WhatsApp DM
+Le plugin OpenClaw WhatsApp supporte la commande slash /new qui crée une nouvelle
+session sans toucher à l'ancienne. **C'est la méthode privilégiée** pour
+redémarrer une conversation WhatsApp DM saturée — préférable à la purge manuelle
+de sessions.json pour les cas non corrompus.
+
+Quand utiliser :
+- Session WhatsApp DM avec context overflow (> 60k tokens)
+- Bouclage suspect après plusieurs heures de discussion
+- Reset volontaire pour démarrer un nouveau sujet
+
+Quand NE PAS utiliser (préférer purge manuelle) :
+- JSONL corrompu (assistant content: [] empty array)
+- Session avec compactionCheckpoints=7+ (irrécupérable)
+- abortedLastRun=true persistant
+
+### Hot-reload config compaction validé
+agents.defaults.compaction.* est correctement hot-reloaded après compose restart.
+Pas besoin de docker compose down/up pour ces changements.
+
+### Bug observable mais sans gravité
+effectiveReserveTokens plafonne à 16384 même avec reserveTokensFloor configuré
+à 20000. Le système gère via fallback compaction multiple. À reporter upstream
+OpenClaw si récurrent.
+
+## 10/6/2026 mercredi ~15:00-15:03 UTC+2 — Fix bug "OK au lieu du cours" cron orange-intraday
+
+### Cause racine
+Le cron `orange-intraday` (id `8cd988b1-d91e-4ecb-8719-c1c72efb0d87`) :
+- prompt terminait par "Réponds par 'OK' une fois fini. PAS de WhatsApp pour l'intraday."
+- delivery configuré en mode=announce, channel=whatsapp, to=+33607148216
+- → l'agent répondait "OK" en signal de fin, et le mode `announce` envoyait
+  systématiquement la dernière réponse à WhatsApp = donc "OK" partait à chaque heure.
+- L'instruction "PAS de WhatsApp pour l'intraday" dans le prompt était ignorée
+  (delivery est piloté par config, pas par prompt).
+
+### Fix appliqué
+Édition du prompt via :
+  `cron edit 8cd988b1-... --message "<nouveau prompt>"`
+Remplacement final :
+  AVANT : "Réponds par 'OK' une fois fini. PAS de WhatsApp pour l'intraday."
+  APRÈS : "Une fois fini, réponds avec UNIQUEMENT cette ligne au format strict :
+           'ORA.PA : <prix>€ (<variation>%)' OU 'ORA.PA : indisponible'
+           PAS de 'OK', PAS d'autre texte, PAS de tableau, PAS de commentaire."
+
+### Validation
+- 15:00 : cron horaire avec ancien prompt → envoi "OK" (état pré-fix)
+- 15:03 : `cron run` manuel avec nouveau prompt → envoi "ORA.PA : 17,83€ (+0,99%)" ✅
+- ✅ format conforme, valeur cohérente (vendredi 6/6 clôture 17,66 → +0,99% = 17,83 OK)
+- À surveiller : prochains crons auto 16:00 et 17:00 mercredi
+
+### Backup
+/volume1/docker/openclaw-data/handoffs/cron-orange-intraday-before-20260610-0303.json
+
+### Apprentissages
+- `cron edit <id> --message "<text>"` est la méthode propre pour modifier un prompt
+- `cron run <id>` permet un test immédiat (debug, ne respecte pas le schedule)
+- Le delivery mode `announce` envoie automatiquement la dernière réponse de l'agent
+  → écrire le prompt pour que la dernière réponse soit le format souhaité
+- Les autres cron Orange (orange-cloture, orange-ouverture) utilisent un pattern
+  similaire, à monitorer mais pas à modifier (semblent OK structurellement)
+
+
+## 10/6/2026 nuit (~22:00-23:48 Paris) — Session marathon résolution amnésie agent
+
+### Phases réussies
+- A. Audit complet (versions, dette technique, ressources)
+- B. Backup pré-MAJ (156 MB préservés, image pre-maj-20260610-2237)
+- C. MAJ OpenClaw 2026.6.1 → 2026.6.5 (sans régression)
+- D. Tests baseline 6/6 pass
+- F. TOOLS.md + MEMORY.md complets avec convention exec
+
+### Découverte majeure — Bug structurel résolu
+Le bug "amnésie Gmail" n'était PAS une vraie amnésie LLM.
+L'agent essayait d'invoquer `gog` comme tool natif (10 fois !).
+La cause : TOOLS.md documentait `gog gmail send --to ...` sans préciser
+que `gog` doit passer par le tool natif `exec` (ou `bash`).
+
+Fix : ajout section 1.0 dans TOOLS.md + section 7 hard constraint :
+"Toute commande CLI (gog, python3, curl, jq, git, node) DOIT être 
+invoquée via `exec` ou `bash`."
+
+### Test validation 23:46 ✅
+Question : "Envoie un mail à tallagrand.thierry@gmail.com..."
+Agent : appelle `tool=exec` avec `gog gmail send -a ... --to ... --subject ... --body ...`
+Résultat : Mail reçu (ID 19eb38051276d01e), agent confirme avec détails.
+
+### Pattern réutilisable (à appliquer aux futures capacités)
+1. Identifier la commande exacte (--help)
+2. Documenter EXPLICITEMENT que ça passe par exec
+3. Donner un exemple concret avec arguments
+4. Mapping question→action
+5. Hard constraint anti-amnésie
+6. Test immédiat après modification
+
+### Reste pour Phase E (en cours dans la nuit)
+- E.1 Refactor generate_chart.py (PNG + tri chronologique)
+- E.2 Reconstruction orange-bourse.md propre
+- E.3-E.5 Test pipeline + cron + WhatsApp PNG
+
+### Backups préservés
+- /volume1/docker/openclaw-backups-pre-maj-20260610-2237/ (compose + data)
+- Image Docker openclaw-gateway:pre-maj-20260610-2237 (rollback ULTIME)
+- TOOLS.md.bak-pre-skills-fix-* (avant tee)
+- TOOLS.md.bak-pre-exec-fix-* (avant section 1.0)
+- MEMORY.md.bak-pre-skills-fix-*
+
+## 11/6/2026 nuit (~00:30-01:45 Paris) — Phase E pipeline PNG complet
+
+### Phase E.1 (infra cairosvg) ✅
+- Dockerfile patché : ajout libcairo2/libpango/libgdk-pixbuf/libffi-dev/shared-mime-info + cairosvg==2.7.1
+- Build OK (~33s) → openclaw-custom:latest sha256:8164c3ae04793...
+- Container UP healthy 5 min après recreate
+- Test cairosvg : PNG 15933 bytes généré
+- Test gog auth list : tallagrand.thierry@gmail.com préservé (3e validation persistance)
+- Patch generate_chart.py : conversion SVG→PNG + horodatage charts/ora-YYYY-MM-DD-HHMM.png + symlink ora-latest.png
+
+### Phase E.2 (reconstruction orange-bourse.md) ✅
+- Script clean_bourse_md.py créé (parse + dédup + tri + retire pollution YAML)
+- Avant : 44 lignes, 5 sections désordonnées avec double 06-05, 10 polluants YAML
+- Après : 34 lignes propres, 4 sections triées (06-05, 06-07, 06-09, 06-10), 0 pollution
+- Régénération graphe 06-10 : 10 mesures, courbe LISSE chronologique (vs zigzag avant)
+- Visualisation PNG validée : 46519 bytes, charte graphique Orange parfaite
+
+### Reste pour Phase E (demain en condition réelle)
+- E.4 : Update prompt cron orange-intraday (ajouter étape send WhatsApp + image PNG)
+- E.5 : Test cron run + validation WhatsApp avec image attachée
+
+### Fichiers ajoutés cette nuit
+- /workspace/scripts/clean_bourse_md.py (nouveau, ~140 lignes)
+- /workspace/charts/ (nouveau dossier)
+- /workspace/charts/ora-2026-06-11-0143.png + symlink ora-latest.png
+
+### Backups préservés
+- Dockerfile.bak-pre-cairosvg-20260611-0014
+- generate_chart.py.bak-pre-png-patch-20260611-XXXX
+- orange-bourse.md.bak-pre-clean-20260611-0140
+- orange-bourse.md.bak-pre-apply-20260611-XXXX
+
+## 11/6/2026 (~01:55-02:10 Paris) — Phase E.4 prompt cron mis à jour
+
+### Cron run manuel à 01:55 — preuve que ancien prompt fonctionne
+- Run "ok" 31.5s, WhatsApp delivered "ORA.PA : 18,02€ (+2,07%)" (capture validée)
+- Note : Yahoo retourne le last close + variation hors séance, normal
+
+### Phase E.4 — Update prompt cron orange-intraday
+- Backup pré-E4 : cron-orange-intraday-pre-E4-XXXX.json
+- Nouveau prompt : 4 étapes (ajout étape 4 message+attachment PNG)
+- Précisions : heure Paris explicite, valeurs cohérentes 10:00-17:30, ora-latest.png comme attachment
+- Cleanup data fictives 11/06 : restauration depuis backup pré-fake
+- Phase E.5 différée à 11/6 matin avant 10h (avant cron auto)
+
+###  Phase E.5 faite 
+- cron run manuel test → vérifier WhatsApp reçoit texte + image PNG
+-  a vérifier et faire si besoin cron auto utilise nouveau prompt → 2e validation
+- Si KO : revert via backup .bak-pre-E4-XXXX
+- Si OK : Phase E entièrement validée, fin Phase E
+
+
+## 23 juin 2026 ~01:15-01:30 UTC+2 — Migration cron email horaire vers rapport quotidien 8h30
+
+### Contexte
+L’utilisateur souhaitait abandonner le rapport Gmail horaire (`hourly-email-check`) au
+profit d’un unique résumé quotidien à 8h30 Europe/Paris, tous les jours (week-end inclus),
+sur WhatsApp.
+
+### Source de vérité identifiée
+Le cron actif n’était PAS dans les fichiers JSON obsolètes (`cron/jobs.json*`) mais dans
+la base SQLite :
+
+- Path : `/volume1/docker/openclaw-data/state/openclaw.sqlite`
+- Table : `cron_jobs`
+- Job ID : `9d43dc31-f6ee-445e-a085-753ca65bc0b0`
+
+### Actions réalisées
+1. **Backup** de `state/openclaw.sqlite`, `workspace/MEMORY.md`, `workspace/TOOLS.md`
+   (timestamp `.bak-20260623-01...`).
+2. **UPDATE SQLite** :
+   - `name` : `hourly-email-check` → `daily-email-report`
+   - `schedule_expr` : `0 * * * *` → `30 8 * * *`
+   - `payload_message` : résumé 24h, format court global + détail important (max 5)
+   - `job_json` : resynchronisé avec les nouvelles valeurs
+   - `next_run_at_ms` : recalculé (OpenClaw applique un `staggerMs` de 5 min max,
+     donc exécution réelle entre 8h30 et 8h35).
+3. **Mise à jour `workspace/MEMORY.md`** :
+   - TODO courant modifié
+   - Apprentissage structurant du 23/6/2026 ajouté
+4. **Mise à jour `workspace/TOOLS.md`** :
+   - Nouvelle section 9 « Gmail daily cron » (schedule, canal, format, source de vérité)
+5. **Archivage** des fichiers JSON obsolètes dans `cron/archived-20260623/` :
+   - `jobs.json.migrated`
+   - `jobs.json.bak`
+   - `jobs-state.json.migrated`
+   - `runs/*.jsonl.migrated` (12 fichiers)
+
+### Validation utilisateur (challenge pré-build)
+- ✅ Tous les jours (week-end inclus)
+- ✅ Résumé des dernières 24h
+- ✅ Renommage en `daily-email-report`
+- ✅ Canal WhatsApp conservé (`+33607148216`)
+- ✅ Format court global + détail important avec date/heure
+- ✅ Mise à jour MEMORY.md / TOOLS.md
+- ✅ Archivage des JSON obsolètes (option B)
+- ✅ Backup SQLite avant mutation
+- ✅ Forçage de `next_run_at_ms`
+- ✅ StaggerMs conservé (exécution 8h30–8h35, acceptable)
+
+### Fichiers impactés
+- `state/openclaw.sqlite` (mutation du job)
+- `workspace/MEMORY.md`
+- `workspace/TOOLS.md`
+- `cron/jobs.json.migrated` → `cron/archived-20260623/`
+- `cron/jobs.json.bak` → `cron/archived-20260623/`
+- `cron/jobs-state.json.migrated` → `cron/archived-20260623/`
+- `cron/runs/*.jsonl.migrated` → `cron/archived-20260623/runs/`
+
+### Prochaine validation attendue
+Vérifier demain matin (~8h30–8h35) que WhatsApp reçoit bien le résumé quotidien avec
+le format convenu. Si format incorrect : ajuster `payload_message` dans SQLite.
+
+
+## 23 juin 2026 ~01:15-01:30 UTC+2 — Migration cron email horaire vers rapport quotidien 8h30
+
+### Contexte
+L’utilisateur souhaitait abandonner le rapport Gmail horaire (`hourly-email-check`) au
+profit d’un unique résumé quotidien à 8h30 Europe/Paris, tous les jours (week-end inclus),
+sur WhatsApp.
+
+### Source de vérité identifiée
+Le cron actif n’était PAS dans les fichiers JSON obsolètes (`cron/jobs.json*`) mais dans
+la base SQLite :
+
+- Path : `/volume1/docker/openclaw-data/state/openclaw.sqlite`
+- Table : `cron_jobs`
+- Job ID : `9d43dc31-f6ee-445e-a085-753ca65bc0b0`
+
+### Actions réalisées
+1. **Backup** de `state/openclaw.sqlite`, `workspace/MEMORY.md`, `workspace/TOOLS.md`
+   (timestamp `.bak-20260623-01...`).
+2. **UPDATE SQLite** :
+   - `name` : `hourly-email-check` → `daily-email-report`
+   - `schedule_expr` : `0 * * * *` → `30 8 * * *`
+   - `payload_message` : résumé 24h, format court global + détail important (max 5)
+   - `job_json` : resynchronisé avec les nouvelles valeurs
+   - `next_run_at_ms` : recalculé (OpenClaw applique un `staggerMs` de 5 min max,
+     donc exécution réelle entre 8h30 et 8h35).
+3. **Mise à jour `workspace/MEMORY.md`** :
+   - TODO courant modifié
+   - Apprentissage structurant du 23/6/2026 ajouté
+4. **Mise à jour `workspace/TOOLS.md`** :
+   - Nouvelle section 9 « Gmail daily cron » (schedule, canal, format, source de vérité)
+5. **Archivage** des fichiers JSON obsolètes dans `cron/archived-20260623/` :
+   - `jobs.json.migrated`
+   - `jobs.json.bak`
+   - `jobs-state.json.migrated`
+   - `runs/*.jsonl.migrated` (12 fichiers)
+
+### Validation utilisateur (challenge pré-build)
+- ✅ Tous les jours (week-end inclus)
+- ✅ Résumé des dernières 24h
+- ✅ Renommage en `daily-email-report`
+- ✅ Canal WhatsApp conservé (`+33607148216`)
+- ✅ Format court global + détail important avec date/heure
+- ✅ Mise à jour MEMORY.md / TOOLS.md
+- ✅ Archivage des JSON obsolètes (option B)
+- ✅ Backup SQLite avant mutation
+- ✅ Forçage de `next_run_at_ms`
+- ✅ StaggerMs conservé (exécution 8h30–8h35, acceptable)
+
+### Fichiers impactés
+- `state/openclaw.sqlite` (mutation du job)
+- `workspace/MEMORY.md`
+- `workspace/TOOLS.md`
+- `cron/jobs.json.migrated` → `cron/archived-20260623/`
+- `cron/jobs.json.bak` → `cron/archived-20260623/`
+- `cron/jobs-state.json.migrated` → `cron/archived-20260623/`
+- `cron/runs/*.jsonl.migrated` → `cron/archived-20260623/runs/`
+
+### Prochaine validation attendue
+Vérifier demain matin (~8h30–8h35) que WhatsApp reçoit bien le résumé quotidien avec
+le format convenu. Si format incorrect : ajuster `payload_message` dans SQLite.