nas-runbooks/common/seam-discipline-hermes.md

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.