seal_content

Vue d’ensemble

seal_content scelle du texte arbitraire (markdown, notes, code source, savoir-faire) en un seul appel MCP, sans nécessiter d’accès shell ni de fichier sur disque préalable. Idéal pour les agents qui n’ont que le protocole MCP (Claude Desktop, agents cloud).

Le flux est : SHA-512 du contenu → écriture dans .seshat/sealed/ (ou ~/.seshat/vault/ selon le projet) → commit git (si repo) → insertion ledger → scellement IP Secure (si configuré) → push best-effort vers Hub (si configuré).

Note

Pour sceller un fichier déjà sur disque, utilisez plutôt seal_file.

Paramètres

project string requis

ID du projet (lettres, chiffres, ., _, -).

title string requis

Titre du contenu (max 200 chars). Utilisé comme nom de fichier (slugifié) et description par défaut de l’entrée du ledger.

content string requis

Le texte à sceller (min 1 char, max 500 000 chars).

asset_types string[] requis

Type(s) d’actif IP protégés. Voir Classification IP pour les 13 valeurs valides.

description string

Description (max 500 chars depuis v1.4.2 — #411) qui apparaîtra sur le certificat eIDAS. L’agent DOIT la rédiger en miroir du contenu (distinct du titre).

Attention

Le certificat eIDAS fige la description au moment du scellement. Le ledger SESHAT, lui, reste éditable via annotate après coup.

objective string

Objectif R&D pour la traçabilité CIR (max 500 chars).

author string

Nom de l’auteur. Défaut : git config user.name.

dry_run boolean

Mode preview. Défaut : true si IP Secure est lié au projet, false sinon. Quand true, retourne un preview sans écrire/commiter/scellement.

force_secret_scan boolean défaut: false

Outrepasse le scan de secrets pré-scellement (#410). À utiliser uniquement après revue manuelle confirmant un faux positif. L’usage est loggué.

Comportement de sécurité (depuis v1.4.2)

Avant toute persistance, le contenu est scanné contre des patterns de secrets connus : clés AWS, tokens GitHub/Slack/Google, JWT, blocs PEM privés, chaînes de connexion DB, assignations password=…. Les placeholders communs (changeme, xxxxxx, <redacted>) sont ignorés.

Si un secret est détecté :

{
  "success": false,
  "reason": "secret_scan_blocked",
  "findings": [
    {
      "rule": "github-token",
      "description": "GitHub personal access token / OAuth / app token",
      "line": 3,
      "snippet": "token: gh***AB"
    }
  ],
  "message": "Pre-seal secret scan blocked: 1 potential secret detected (github-token). Redact the content and retry, or pass `force_secret_scan: true` if these are false positives."
}

Réflexe attendu de l’agent : présenter le findings à l’utilisateur, proposer une version expurgée, puis re-seal_content avec le contenu nettoyé. Cf. l’épisode Alberto du 26 mai 2026 — c’est le réflexe qu’on cherche à institutionnaliser.

Réponse

{
  "title": "Réunion stratégique Q1 2026",
  "reference": "content:476b712a",
  "fingerprint": "476b712a0658003cd68931ca49f8c6e2392839836c1a0bedc56c3f5089d422d8012656a5115457197fb8069dcf87fb33a7f7e3dd2782f6d8f9cf2be7ebf3d1a6",
  "file_path": "/path/to/repo/.seshat/sealed/2026-05-27-reunion-strategique-q1-2026.md",
  "commit_sha": "abc1234567890",
  "timestamp": "2026-05-27T09:08:47.560Z",
  "ipsecure_contribution_id": "mwMWTpjmu3",
  "ipsecure_certificate_url": null,
  "ipsecure_setup_hint": null,
  "project_auto_created": false,
  "dry_run": false
}

ipsecure_certificate_url string | null

Souvent null à la réponse immédiate — Jinnove génère le certificat de manière asynchrone. Récupérer plus tard avec fetch_certificate.

reference string

Préfixée par content: + 8 premiers chars du SHA-512 (ou du commit SHA si commit git effectué). Permet de retrouver l’entrée via /odata/ledger?$filter=reference eq 'content:476b712a'.

Idempotence

Si le même contenu est seal_content-é deux fois pour le même projet :

• Le SHA-512 est identique → fingerprintExists() détecte le doublon.
• Aucune nouvelle entrée ledger n’est créée, aucun fichier réécrit, aucune contribution IP Secure dupliquée.
• La réponse retourne le fingerprint mais file_path: null et commit_sha: null (rien n’a été fait).

Stockage

Cas	Emplacement
Projet avec repo_path configuré	<repo_path>/.seshat/sealed/<YYYY-MM-DD>-<slug>.md — commité automatiquement
Projet sans repo_path	~/.seshat/vault/<project_id>/<YYYY-MM-DD>-<slug>.md — pas de commit

Le fichier sealed est byte-identique au contenu d’entrée (pas de réécriture, normalisation, ni reformatage). Le SHA-512 du fichier sealed == le fingerprint stocké au ledger.

Workflow type

1. Préparer le contenu

   Conversation, note d’analyse, fragment de code — texte arbitraire jusqu’à 500 KB.

2. Premier appel (dry_run par défaut si IP Secure lié)

   Scelle cette conversation pour mon projet en tant que savoir_faire

3. Présenter le preview à l’utilisateur

   L’agent montre titre, description, asset_types, objectif, fingerprint prévu. Attend confirmation EXPLICITE.

4. Re-appel avec dry_run: false après confirmation

5. Récupérer le certificat eIDAS plus tard

   Si IP Secure est lié et que ipsecure_certificate_url est null, attendre 1-5 min puis fetch_certificate(ledger_id).

Voir aussi

• seal_file — sceller un fichier déjà sur disque
• seal — sceller un artefact git (commit, PR, tag)
• annotate — modifier la qualification (asset_types, description, objective) après coup
• fetch_certificate — récupérer l’URL eIDAS asynchrone