# 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.