Was Ihr Agent vorbereitet, was Sie unterschreiben

Ce que `save_version` fait réellement

`save_version` enregistre un instantané NOMMÉ de l'état courant du schéma. Son rôle est de BORNER une salve de travail — un point de repère qu'on peut retrouver, comparer, ou vers lequel revenir — pas de déclencher quoi que ce soit d'autre.

save_version({ label: "Avant refonte de la filiale Tech" })
// … tes écritures …
save_version({ label: "Refonte Tech — Q3 2026" })

L'agent dispose aussi de `list_versions`, `get_version`, `diff_versions` pour inspecter et comparer l'historique, et de `restore_version` pour revenir à un état antérieur. Les quatre lisent ou remplacent le schéma — aucun des cinq outils du domaine versions ne touche à une signature.

Où passe la frontière, précisément

Les trois dernières lignes ne sont pas absentes par oubli : `version_proposals` et `version_signoffs` (les deux tables qui portent ce cycle) ne sont écrites que par des routes HTTP consommées par l'interface web. Aucun outil MCP ni chat ne les atteint — un agent, aussi capable soit-il, ne peut littéralement pas appeler ce qui n'existe pas dans le registre qu'il reçoit à la connexion.

Ce que devient une version scellée

Une fois scellée par le propriétaire, une version signée est immuable : le registre des signatures est append-only, et une tentative de modification — même par le propriétaire, même par la base de données directement — est bloquée. L'attestation qui en résulte porte l'identité de la version, la liste des signataires, et une empreinte SHA-256 du contenu exact qui a été signé — vérifiable indépendamment, sans faire confiance à OrgGen sur parole.

C'est ce document — pas la version elle-même — qui s'annexe à un pacte d'associés : il prouve, cryptographiquement, que le schéma signé aujourd'hui est bien celui qui a été présenté au moment de la signature.