diff --git a/_INDEX.md b/_INDEX.md
index 71d9dc7..d17d97e 100644
--- a/_INDEX.md
+++ b/_INDEX.md
@@ -207,3 +207,6 @@
 - [common/guardrails-flotte-hermes-hard-stop-tirith-verificateur-12-08-2026.md](common/guardrails-flotte-hermes-hard-stop-tirith-verificateur-12-08-2026.md) -- hard_stop_enabled et tirith_enabled actives sur les 4 instances (etaient false), verificateur delegate_task croise (NAS genere DeepSeek/verifie Mimo V2.5, hermes-nabil inverse) ; faille provenance mail->RAG confirmee par lecture code mais pas corrigee (chantier a part) ; hermes-agent-tt trouve down 8h (mort non-propre, cause inconnue), hermes-workspace-perso bloque par port 3030 orphelin (12/08/2026)
 - [hermes-tt/nyora-notes-tt-backfill-72h-perte-silencieuse-429-resync-error404-16-08-2026.md](hermes-tt/nyora-notes-tt-backfill-72h-perte-silencieuse-429-resync-error404-16-08-2026.md) -- Backfill mail 72h termine (643->4322 notes). Deux pieges : (1) 444 messages perdus en silence sur 63 dossiers (18%) -- 66% sur HTTP 429 embeddings jete au lieu de reessaye, reste sur raisonnement mimo-v2.5 tronquant le JSON (max_tokens partage) ; dossier passait 'done' quand meme, bilan ne comptait pas les echecs -- fix retries+backoff, max_tokens 2500->8000, compteur messages_ignores remonte au bilan (0 perte en tranche finale). (2) 122 error_404 mesuraient un resolveur de chemin perime (bugs C/D corriges le 10/08), pas des dossiers absents -- 105/122 resolubles apres confrontation normalisee a un /folders frais. Regle generale : tout pipeline lot-LLM doit exposer un compteur d'echecs a cote du compteur de succes (16/08/2026)
 - [common/synology-scp-sftp-indisponible-cat-ssh.md](common/synology-scp-sftp-indisponible-cat-ssh.md) -- scp/sftp echouent systematiquement vers ce DSM ("No such file or directory" malgre chemin valide) -- sous-systeme SFTP indisponible pour l'utilisateur/cle d'automatisation, ssh lui-meme non affecte. Contournement : `cat fichier | ssh nas 'cat > dest'` (tar czf/xzf pour un dossier). Rencontre 2x en contextes differents (git bundle nas-runbooks, deploiement fichier partage aux 3 instances Hermes) -> promu en runbook transverse plutot que note de session isolee (16/08/2026)
+- [common/seam-discipline-hermes.md](common/seam-discipline-hermes.md) -- Discipline service/fournisseur/consommateur pour toute nouvelle capacite Hermes, inspiree dsh sans en dependre (17/08/2026)
+- [common/regle-source-generation-documentaire-zone-sud.md](common/regle-source-generation-documentaire-zone-sud.md) -- Regle "jamais inferer au-dela de la source" deployee dans dco-generation-tt, gsd-ao-evaluation, courriers-officiels-tt ; few-shot a completer avec Nabil (17/08/2026)
+
diff --git a/common/PROTOCOL-INFRA.md b/common/PROTOCOL-INFRA.md
index 9e2fa5a..93147b1 100644
--- a/common/PROTOCOL-INFRA.md
+++ b/common/PROTOCOL-INFRA.md
@@ -414,3 +414,12 @@ d'avoir rien lu : le premier rapport a donc affiche "[OK]" sur une panne complet
 REFLEXE : verifier que le critere de succes est DISCRIMINANT vis-a-vis des modes d'echec connus.
 Ici il a fallu exiger `status == 'done'` en plus du compteur, et prevoir un verdict distinct
 "NON CONCLUANT" -- ni succes, ni anomalie -- pour ce qui n'a pas ete mesure.
+
+## REGLE -- Discipline "seam" pour toute nouvelle capacite Hermes (2026-08-17)
+
+Avant d'ajouter une nouvelle capacite a une instance Hermes (nouvel outil, nouveau skill qui appelle un service externe, nouvelle integration), definir explicitement trois choses avant d'ecrire le premier fichier : (1) le service -- quelle fonction precise est rendue disponible et par quel contrat (entree/sortie) ; (2) le fournisseur -- quel composant l'implemente reellement (API externe, script local, autre instance Hermes) et ou vit sa configuration/ses credentials ; (3) le consommateur -- quelle(s) instance(s)/quel(s) skill(s) l'utilisent, et via quel mecanisme d'appel. Objectif : eviter l'ajout ad hoc ou service/fournisseur/consommateur sont meles dans un seul script sans frontiere claire. Inspire de l'architecture DeepSeek Harness (dsh, evalue le 15/08/2026, non adopte tel quel car encore en developer preview) sans en dependre. S'applique a toute nouvelle capacite a partir du 17/08/2026 ; pas de reprise retroactive des skills existants. Detail : common/seam-discipline-hermes.md.
+
+## REGLE -- Ne jamais inferer au-dela de la source, generation documentaire Zone Sud (2026-08-17)
+
+Regle distincte de l'anti-invention benchmarks du 27/07/2026 (qui couvre la veille/recherche). Ici, toute valeur inseree dans un document officiel genere pour la Direction Zone Sud (DCO, courrier, evaluation AO, notification) doit venir textuellement d'une source verifiee pour ce dossier precis, jamais d'une estimation, d'un arrondi de convention, ou d'une valeur dupliquee d'un autre dossier par plausibilite. Champ absent ou ambigu -> le signaler a Nabil et marquer `[A VERIFIER]` dans le document plutot que le remplir a l'estime. Deploye le 17/08/2026 dans dco-generation-tt, gsd-ao-evaluation, courriers-officiels-tt (skills hermes-tt, non versionnes sur Gitea -- data/ gitignore, persistance via volume Docker uniquement). Reste a faire, avec Nabil : peupler `references/exemples-valides/` de chaque skill avec 2-3 documents deja valides, pour un cadrage few-shot. Detail : common/regle-source-generation-documentaire-zone-sud.md.
+
diff --git a/common/regle-source-generation-documentaire-zone-sud.md b/common/regle-source-generation-documentaire-zone-sud.md
new file mode 100644
index 0000000..146841f
--- /dev/null
+++ b/common/regle-source-generation-documentaire-zone-sud.md
@@ -0,0 +1,17 @@
+# Ne jamais inferer au-dela de la source — generation documentaire Zone Sud
+
+Deploye le 17/08/2026 dans trois skills hermes-tt : `achats/dco-generation-tt`, `achats/gsd-ao-evaluation`, `achats/courriers-officiels-tt`. Regle distincte de la regle anti-invention benchmarks du 27/07/2026 (celle-ci couvre la veille et la recherche documentaire ; celle-ci couvre la production de documents officiels pour la Direction Zone Sud).
+
+## La regle
+
+Toute valeur inseree dans un document final (montant, reference AO, denomination fournisseur, clause contractuelle, date) doit venir textuellement d'une source verifiee pour ce dossier precis : document officiel de l'AO, export Baserow, ou fichier deja valide par Nabil. Jamais d'estimation, d'arrondi de convention, ou de valeur dupliquee d'un autre dossier par simple plausibilite.
+
+Si une donnee necessaire est absente ou ambigue dans la source : le signaler explicitement a Nabil avant de produire le document, et marquer le champ `[A VERIFIER]` dans le fichier plutot que de le remplir a l'estime. Un champ visiblement marque est corrigeable en 30 secondes ; une valeur inventee qui a l'air correcte peut passer inapercue jusqu'a la signature d'un document officiel Tunisie Telecom.
+
+## Ou c'est applique
+
+Le bloc de regle est insere directement dans le corps de chaque SKILL.md, juste apres le titre H1, pour qu'il soit lu avant toute instruction de generation. Ces trois skills sont specifiques a hermes-tt et vivent dans `data/skills/achats/` — non versionnes sur Gitea (le dossier `data/` est gitignore sur les repos d'instance Hermes), persistance uniquement via le volume Docker.
+
+## Reste a faire (avec Nabil, pas depuis mcp-nas seul)
+
+Peupler un dossier `references/exemples-valides/` dans chacun de ces trois skills avec 2-3 documents deja valides par Nabil, pour donner un cadrage few-shot concret plutot qu'une regle abstraite seule. Choix des documents a faire par Nabil — ce sont des documents officiels Zone Sud, pas a Claude de les selectionner seul.
diff --git a/common/seam-discipline-hermes.md b/common/seam-discipline-hermes.md
new file mode 100644
index 0000000..43505a4
--- /dev/null
+++ b/common/seam-discipline-hermes.md
@@ -0,0 +1,23 @@
+# Discipline "seam" pour toute nouvelle capacite Hermes
+
+Decide le 17/08/2026, dans la foulee de l'evaluation DeepSeek Harness (dsh) du 15/08/2026. Ne remplace rien d'existant, s'applique aux capacites ajoutees a partir de cette date.
+
+## Le principe
+
+Avant d'ecrire le premier fichier d'une nouvelle capacite Hermes (nouvel outil, nouveau skill qui appelle un service externe, nouvelle integration), definir explicitement trois roles separes :
+
+1. **Service** — quelle fonction precise est rendue disponible, avec quel contrat d'entree/sortie. Pas "un skill qui fait des trucs avec Baserow", mais "recuperer les lignes d'une table Baserow filtrees par region, retourne du JSON".
+2. **Fournisseur** — quel composant implemente reellement ce service (API externe, script local, autre instance Hermes), et ou vivent sa configuration et ses identifiants.
+3. **Consommateur** — quelle(s) instance(s) et quel(s) skill(s) appellent ce service, et par quel mecanisme (appel direct, MCP, HTTP interne).
+
+## Pourquoi
+
+Sans cette separation, un script fini par melanger les trois roles : logique metier, appel API, et gestion des identifiants dans le meme fichier. Resultat observe sur l'infra actuelle : difficile a auditer (ou est la logique reelle ?), difficile a deplacer d'une instance a l'autre, casse en cascade des qu'on touche a un seul morceau.
+
+## Ce qu'on emprunte a dsh, ce qu'on n'adopte pas
+
+dsh (DeepSeek Harness, evalue le 15/08/2026) applique cette discipline de facon stricte et outillee. On en retient le principe sans installer le projet lui-meme : il est encore en developer preview, avec des ruptures de compatibilite annoncees a venir — contraire a la regle "ne jamais substituer sans accord explicite" appliquee a de l'infra en prod. Aucun runbook dedie pour cette evaluation a ce jour ; a creer si dsh revient a l'ordre du jour.
+
+## Application pratique
+
+Pas de reprise retroactive des skills existants (achats/*, productivity/*, etc.) — l'effort de refonte ne se justifie pas pour ce qui fonctionne deja. La regle s'applique au prochain ajout, quel qu'il soit : avant d'ecrire du code, ecrire une ligne pour chacun des trois roles.