Partie VI — Documents signés par Git : l'artefact de signature (GCSIG)

Déclencheur S6 : un contrat doit être signé de manière native Git. Mais dès avant la signature, il doit être possible de retracer à qui le document a été présenté, quand il a été approuvé et quand il a été signé. Où cela est-il consigné, si le document original lui-même doit rester immuable ?

Le problème : les événements ont besoin d'un emplacement

Les parties I à III montrent comment un document (document original), ses métadonnées (sidecar), ses documents de signature/événements et le processus (GCPN) interagissent. Mais un point sensible reste ouvert : les événements d'un document donné — présentation (presented), approbation (accepted), signature (signed) — ont besoin d'un emplacement propre à chaque document, et ce dès le brouillon.

Le document original lui-même ne doit pas porter cet emplacement. Il est — dès qu'il est signé — immuable : toute modification ultérieure (même d'un simple indicateur de statut) modifie son SHA-256 et invalide ainsi une signature déjà effectuée. Le brouillon lui-même peut déjà être la version finale ; par conséquent, aucun statut, aucun historique, aucune note de processus ne doit figurer dans le document original.

La solution : un artefact de signature par document (`*.gcsig.md`)

À chaque document original .md destiné à la signature appartient, dès le brouillon, un artefact de signature {name}.gcsig.md :

Classe V7GUID GCSIG, schéma gcsig-1.4. Depuis la version 1.4, le GCSIG peut intégrer le contenu du document original (content, p. ex. business-meal-receipt-1.0 pour un justificatif de frais de repas), la provenance OCR (ocr, TrustVector-BitVector), le bloc de signature (signature, avec fac-similé) et un bloc sidecar intégré (source) — il remplace ainsi, pour les justificatifs signés, le .gc.md séparé (voir ci-dessous). 1.3/1.2/1.1/1.0 restent des schémas hérités valides.
Conteneur de phases mutable (comme le GCPN) : le cycle de vie de la signature est tenu sous forme de vecteur de bits de phases 32 bits ; les changements d'état sont de simples opérations sur les bits.
Ancre de contenu : subject.sha = SHA-256 du document original. L'artefact est ainsi lié à la version concrète et résistant à la réécriture de l'historique.
Déjà existant au stade du brouillon (phase draft) ; signer/gpg ne sont renseignés qu'au moment de la signature.

Création (outil gc-docsign) :

gc-docsign gcsig --doc "<ur-doc.md>"            # ab Entwurf, Phase draft
gc-docsign gcsig --doc "<ur-doc.md>" --phase presented
gc-docsign gcsig --doc "<ur-doc.md>" --phase accepted
gc-docsign gcsig --doc "<ur-doc.md>" --phase signed --key <fingerprint>

Le vecteur de bits de phases

Phase	Bit	Valeur	Signification
`draft`	0	1	Brouillon (point de départ)
`presented`	1	2	soumis à la signature / présenté
`accepted`	2	4	accepté / approuvé
`signed`	3	8	signé
`denied`	4	16	refusé
`withdrawn`	5	32	retiré
`revoked`	6	64	révoqué
`expired`	7	128	expiré
`superseded`	8	256	remplacé
`verified`	9	512	vérification réussie (modificateur orthogonal)

Les bits s'accumulent par OR dans phases.phases_result ; current_phase est déduit selon l'ordre de priorité (revoked > superseded > … > draft). verified est un modificateur orthogonal (pas une étape propre du cycle de vie). Cette sémantique des indicateurs correspond à l'exigence « événements sous forme de BitVector » (pas de type union, car cumulatif).

Le bloc de signature dans le document original

Le document original reste immuable, mais reçoit, après le bloc de signatures, une section explicative ## Signatur (GCSIG) qui nomme l'artefact de signature associé :

## Signatur (GCSIG)

Diese Vereinbarung ist für **GC-Signatur** erstellt. …

- **Signatur-Artefakt (GCSIG):** `<uuidV7>`      ← der „Name" (docUid)
- **Titel:** `<basename>.gcsig.md`               ← Dateiname
- **Verfahren:** Textform (§ 126b BGB) mit Facsimile; GC-Signatur (GPG / signierter Git-Commit)
- **Zeichner:** <Name> (Rolle)

La uuidV7 (= docUid du GCSIG) est dérivée sans circularité de l'identité du sujet (nom de base du document/ID de contrat) — non du SHA de ce document —, afin qu'elle puisse figurer dans le document original sans rendre instable l'ancre de signature. Un simple renvoi au nom de fichier serait possible ; la uuidV7 citée rend toutefois l'artefact identifiable par son nom et est — parce qu'elle repose sur l'identité plutôt que sur le contenu — stable. Le statut, le processus et les événements figurent exclusivement dans l'artefact de signature et/ou le GCPN.

Délimitation par rapport aux artefacts voisins

Artefact	Rôle	Mutabilité
Document original (`{name}.md`)	Document source avec texte contractuel + fac-similé	immuable à partir de la signature
Sidecar du document original (`{name}.md.gc.md`)	Métadonnées ; SHA-256 = SSoT	mutable
Artefact de signature (`{name}.gcsig.md`)	Cycle de vie de la signature par document, dès le brouillon	mutable (conteneur de phases)
GCPN (`{name}.gcpn.md`)	Processus/dossier ; `parents[]`/`children[]`	mutable
GCSIG (Commit) (`{abbrev}.gcsig.md`)	Git-Commit signé par GPG	immuable

Le GCSIG comme sidecar — et le passage `.gc.md` → `.gcsig.md`

L'artefact de signature n'est pas un simple document supplémentaire. Deux cas sont à distinguer :

Fonction de sidecar (document original MD natif). Si le document original signé se présente nativement en Markdown — pas de scan, pas de PDF, pas de photo —, le *.gcsig.md peut servir en même temps de sidecar : il porte alors (comme un .gc.md) l'ancre de contenu (SHA-256), le docUid et les métadonnées ainsi que le cycle de vie de la signature dans un seul artefact. Un .gc.md séparé n'est pas indispensable pour cela.
Passage .gc.md → .gcsig.md (PDF signé). Si un PDF (ou similaire) est signé, le .gc.md cataloguant peut passer à un .gcsig.md. Aucune information n'est perdue ce faisant — le contenu du sidecar (ancre, docUid, classe, métadonnées) est transféré dans l'artefact de signature. Mais le statut du document original et son utilisation changent : un justificatif simplement catalogué devient un document original signé doté de son propre cycle de vie de signature (vecteur de bits de phases). Aucun sidecar concurrent ne doit coexister — le contenu est transféré, non dupliqué.

En bref : le GCSIG est le seul endroit où vit la signature de ce document — que ce soit comme artefact de signature pur, en rôle de sidecar ou comme successeur d'un .gc.md.

L'artefact de signature est référencé par le GCPN via l'arête d'arbre (GCSIG:{docUid}) ; inversement, il nomme son processus via gcpn_ref. Pour les objets Git (commit/tree/tag/PR), le GCSIG reste en revanche un artefact immuable (gc-docsign gcsig <repo> --commit <sha>).

Règles (normatives)

Pour chaque document original destiné à la signature, un *.gcsig.md est créé dès le brouillon (schéma gcsig-1.4) ; sans cet artefact, les événements ne peuvent pas être consignés.
Le document original reste immuable : aucun statut, aucune indication de processus/d'historique/ d'auto-hachage ; uniquement le bloc ## Signatur (GCSIG) avec renvoi au nom de fichier.
Statut/événements vivent dans l'artefact de signature et/ou le GCPN.
Un *.gcsig.md issu d'une signature gc (signature de commit) est un document original immuable ; l'artefact par document (document) est en revanche un conteneur de phases mutable.
Pour un document original MD natif, le *.gcsig.md peut être en même temps sidecar (métadonnées + cycle de vie dans un seul artefact). Pour un PDF signé, le .gc.md peut passer à un .gcsig.md — aucune perte d'information (transférer le contenu), mais statut/utilisation du document original modifiés ; aucun sidecar concurrent.

Renvois

Partie I — Forme textuelle — document original, sidecar, document de signature, GCPN.
Partie II — FES & Fac-similé — ancrage FES, couche de fac-similé.
Partie IV — PII, GPG & Governikus — niveau des clés.
Outil et schéma : work/OSS/gc-docsign (docs/gcsig.md), schéma gcsig-1.4 (racine normative OSS .gitcover/schemas/).

Créé : 261008 | Éditeur : ORG-1 (espace réservé) | Série : digital-signage