diff --git a/_INDEX.md b/_INDEX.md
index 8dadd2c..07b7c28 100644
--- a/_INDEX.md
+++ b/_INDEX.md
@@ -162,3 +162,5 @@
 
 - [common/smart-approvals-deny-rules-4-instances.md](common/smart-approvals-deny-rules-4-instances.md) -- approvals.mode smart + deny rules sur les 4 instances Hermes, auxiliary.approval route vers deepseek-v4-flash (jamais mimo-v2.5), exception documentee hermes-nabil VPS (27/07/2026)
 
+- [common/veille-chunking-nyora-root-cause.md](common/veille-chunking-nyora-root-cause.md) -- Root cause des 24 tool_calls casses hermes-nyora : prompt du job veille ordonnait un heredoc unique pour 20 items sans limite, pas un probleme mimo-v2.5 ; fix construction chunkee (27/07/2026)
+
diff --git a/common/PROTOCOL-INFRA.md b/common/PROTOCOL-INFRA.md
index 972b739..d47099c 100644
--- a/common/PROTOCOL-INFRA.md
+++ b/common/PROTOCOL-INFRA.md
@@ -181,3 +181,7 @@ Avant de presenter un chiffre (benchmark, prix, score) dans un rapport : le chif
 
 Passage de manual/auto (valeur invalide sur tt) a `smart` sur hermes-perso, hermes-tt, hermes-nyora, hermes-nabil. `cron_mode: deny` inchange (un job planifie qui tombe sur une commande signalee reste bloque, jamais auto-approuve). Ajout de `approvals.deny` (patterns absolus, bloques avant meme le jugement du modele auxiliaire ou un /yolo) -- rm -rf /*, dd vers /dev/*, redirection vers .env/credentials/secrets, git push --force, docker volume rm/system prune, DROP TABLE/DATABASE ; + TRUNCATE et DELETE Baserow en plus sur hermes-tt. `auxiliary.approval` route explicitement vers deepseek-v4-flash (jamais mimo-v2.5, meme quand c'est le modele principal de l'instance) -- le juge de securite doit etre le modele le plus fiable des deux, pas le defaut. Exception : hermes-nabil (VPS) n'a aucune route deepseek disponible, laisse en auto (mimo-v2.5), ecart documente. Detail : common/smart-approvals-deny-rules-4-instances.md.
 
+## FIX -- root cause des tool_calls casses sur hermes-nyora : prompt du job veille, pas mimo-v2.5 (2026-07-27)
+
+Les 24 incidents "Unrepairable tool_call arguments" venaient du prompt du cron veille-ia-nexum-4ee61494 qui ordonnait d'ecrire jusqu'a 20 analyses (champs sans limite de longueur) en UN SEUL heredoc -- exact anti-pattern du skill generation-contenu-volumineux, qui perd face a une instruction de prompt precise et contraire. Ce n'etait pas un probleme de fiabilite du modele. Fix : prompt reecrit pour une construction chunkee (1 fichier /tmp/veille_item_NN.json par opportunite, assemblage par script Python, jamais un nouvel appel LLM pour la fusion). Reflexe a generaliser : avant de blamer un modele sur des echecs de tool_call recurrents sur une tache precise, verifier D'ABORD si le prompt de cette tache contredit la regle de generation chunkee. Detail : common/veille-chunking-nyora-root-cause.md.
+
diff --git a/common/veille-chunking-nyora-root-cause.md b/common/veille-chunking-nyora-root-cause.md
new file mode 100644
index 0000000..f41ef01
--- /dev/null
+++ b/common/veille-chunking-nyora-root-cause.md
@@ -0,0 +1,46 @@
+# Root cause des 24 tool_calls casses sur hermes-nyora : le prompt du job veille ordonnait l'anti-pattern
+
+**Instance auteur** : Claude
+**Date** : 2026-07-27
+**Tags** : [infra, veille, mimo-v2.5, prompt-cron, transverse]
+**Statut** : valide
+
+---
+
+## Probleme
+
+24 occurrences de `Unrepairable tool_call arguments for terminal — replaced with empty object` sur hermes-agent-nyora en 12 jours de logs, systematiquement sur l'ecriture de `/opt/data/veille_enrich.json` ou `/tmp/veille_telegram.md`, et systematiquement aux horaires du cron veille (6h/11h/19h UTC). Diagnostic initial (attribue a tort a mimo-v2.5) : voir note du 27/07 sur les benchmarks/fiabilite mimo.
+
+## Contexte et contraintes (cause racine reelle)
+
+Le mecanisme de reparation JSON (`agent/message_sanitization.py`) tente de requilibrer les accolades/crochets manquants, mais echoue quand la coupure tombe **en plein milieu d'une chaine de texte** (ex: `"resu` coupe au milieu du mot "resume") -- ce n'est pas un JSON mal forme reparable, c'est une generation tronquee avant la fin. Cause = troncature de sortie, meme famille que le probleme deja documente dans `common/generation-chunkee-taches-volumineuses.md` (02/07/2026, DeepSeek V4 Flash, hermes-perso).
+
+Le vrai coupable : le prompt du job cron `veille-ia-nexum-4ee61494` (jobs.json) instruisait explicitement d'ecrire **jusqu'a 20 opportunites, chacune avec des champs "why" et "angle" explicitement sans limite de longueur ("aussi longue que necessaire, pas de limite artificielle")**, le tout en **UN SEUL heredoc terminal()**. C'est l'exact anti-pattern que le skill `generation-contenu-volumineux` (deja deploye sur les 3 instances depuis le 02/07) est cense empecher -- mais une instruction explicite et precise dans un prompt de tache prime sur un reflexe de skill generique, quel que soit le modele. Le probleme n'etait donc pas une fiabilite intrinseque de mimo-v2.5, mais un conflit entre une regle generale (skill) et une instruction specifique plus forte (prompt du job) qui n'avait jamais ete alignee dessus.
+
+## Ce qui NE fonctionne PAS
+
+| Tentative | Erreur / limite | Raison |
+|-----------|------------------|--------|
+| Compter sur le skill generation-contenu-volumineux seul pour corriger le comportement | Echec persistant (24 incidents sur 12 jours) | Une instruction explicite et precise ("utilise un heredoc pour tout ecrire") dans le prompt de la tache prime sur la regle generale du skill |
+| Attribuer le probleme a la fiabilite de mimo-v2.5 et chercher a changer de modele | Aurait masque la vraie cause | N'importe quel modele finit par tronquer 20 analyses detaillees sans limite dans un seul appel -- ce n'est pas specifique a mimo |
+
+## Solution validee
+
+Prompt du job `veille-ia-nexum-4ee61494` (jobs.json de hermes-nyora) modifie : l'etape d'ecriture de `veille_enrich.json` passe d'un heredoc unique a une construction chunkee explicite --
+
+1. Un fichier temporaire distinct par opportunite (`/tmp/veille_item_NN.json`, NN = 01 a 20), un heredoc terminal() separe par item.
+2. Assemblage des fichiers en un seul array JSON via UNE commande Python (`json.load` par fichier trie, `json.dump` final) -- jamais un nouvel appel LLM pour la fusion.
+3. Verification du nombre d'objets avant de continuer, puis nettoyage des fichiers temporaires.
+4. Suite du job (ingestion, verification INGEST_OK) inchangee.
+
+Backup de jobs.json avant modif : `cron/jobs.json.bak-20260727-1713`. Container `hermes-agent-nyora` redemarre, `next_run_at` recalcule correctement (19h00 UTC le jour meme) sans intervention manuelle.
+
+## Verification
+
+Prochain run reel (19h00 UTC, 27/07) : confirmer dans `/opt/data/logs/errors.log` l'absence de nouvelle occurrence de `Unrepairable tool_call arguments` sur ce job, et que `veille_enrich.json` contient bien autant d'objets que d'opportunites retenues.
+
+## References
+
+- common/generation-chunkee-taches-volumineuses.md (regle generale dont le prompt du job s'ecartait)
+- common/veille-nexum-rich-job-20-sources.md (bascule vers la veille riche 20 sources, contexte de l'augmentation de volume)
+- Note memoire 27/07 : diagnostic initial (a tort) attribue a la fiabilite de mimo-v2.5