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

Déclencheur S6 : Un contrat doit être signé de manière Git-native. Mais déjà 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 l'Ur-Doc 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 (Ur-Doc), ses métadonnées (Sidecar), ses Signatur-Docs/Events et le processus (GCPN) interagissent. Mais un point sensible reste ouvert : les événements d'un document individuel — présentation (presented), approbation (accepted), signature (signed) — ont besoin d'un emplacement propre à chaque document, et ce dès le brouillon.

L'Ur-Doc 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 flag 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 ; en conséquence, aucun statut, aucun historique, aucune mention de processus ne doit figurer dans l'Ur-Doc.

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

À chaque Ur-Doc .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 1.4, le GCSIG peut intégrer le contenu de l'Ur-Doc (content, p. ex. business-meal-receipt-1.0 pour un justificatif de repas d'affaires), 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 .v7g.md séparé (voir ci-dessous). 1.3/1.2/1.1/1.0 restent des schémas Legacy valides.
Conteneur de phases mutable (comme le GCPN) : le cycle de vie de la signature est tenu sous forme de BitVector de phases 32 bits ; les changements d'état sont de simples opérations sur bits.
Ancre de contenu : subject.sha = SHA-256 de l'Ur-Doc. L'artefact est ainsi lié à la version concrète et résistant à la réécriture d'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 BitVector de phases

Phase	Bit	Valeur	Signification
`draft`	0	1	Brouillon (point de départ)
`presented`	1	2	présenté pour signature / affiché
`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érivé selon la précédence (revoked > superseded > … > draft). verified est un modificateur orthogonal (pas une étape propre du cycle de vie). Cette sémantique de flags correspond à la spécification « Events als BitVector » (pas de type union, car cumulatif).

Le bloc de signature dans l'Ur-Doc

L'Ur-Doc reste immuable, mais reçoit, après le bloc de signatures, une section explicative ## Signatur (GCSIG) qui nomme l'artefact de signature correspondant :

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

L'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 l'Ur-Doc sans rendre instable l'ancre de signature. Une simple référence au nom de fichier serait possible ; l'uuidV7 citée rend toutefois l'artefact identifiable par son nom et est — parce que fondée 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é
Ur-Doc (`{name}.md`)	Document source avec texte contractuel + fac-similé	immuable à partir de la signature
Ur-Doc-Sidecar (`{name}.md.v7g.md`)	Métadonnées ; SHA-256 = SSoT	mutable
Artefact de signature (`{name}.gcsig.md`)	Cycle de vie de 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`)	Commit Git signé par GPG	immuable

Le GCSIG comme Sidecar — et la transition `.v7g.md` → `.gcsig.md`

L'artefact de signature n'est pas un simple document additionnel. Deux cas doivent être distingués :

Fonction Sidecar (Ur-Doc MD natif). Si l'Ur-Doc 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 .v7g.md) l'ancre de contenu (SHA-256), le docUid et les métadonnées et le cycle de vie de signature dans un seul artefact. Un .v7g.md séparé n'est pas indispensable pour cela.
Transition .v7g.md → .gcsig.md (PDF signé). Si un PDF (ou similaire) est signé, le .v7g.md existant, cataloguant, peut devenir un .gcsig.md. Aucune information n'est perdue — le contenu du Sidecar (ancre, docUid, classe, métadonnées) est transféré dans l'artefact de signature. Mais le statut de l'Ur-Doc et son utilisation changent : un justificatif simplement catalogué devient un Ur-Doc signé avec son propre cycle de vie de signature (BitVector 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 pur artefact de signature, en rôle de Sidecar ou comme successeur d'un .v7g.md.

L'artefact de signature est référencé par le GCPN via l'arête de l'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 Ur-Doc 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.
L'Ur-Doc reste immuable : aucun statut, aucune indication de processus/ d'historique/d'auto-hash ; uniquement le bloc ## Signatur (GCSIG) avec référence 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 Ur-Doc immuable ; l'artefact par document (document) est en revanche un conteneur de phases mutable.
Pour un Ur-Doc 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 .v7g.md existant peut devenir un .gcsig.md — aucune perte d'information (transférer le contenu), mais statut/utilisation de l'Ur-Doc modifiés ; aucun Sidecar concurrent.

Renvois

Partie I — Forme textuelle — Ur-Doc, Sidecar, Signatur-Doc, GCPN.
Partie II — FES & Fac-similé — raccordement FES, couche 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 (OSS-Normative-Root .gitcover/schemas/).

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