Teil VI — Git-signierte Dokumente: das Signatur-Artefakt (GCSIG)

Auslöser S6: Ein Vertrag soll Git-nativ gezeichnet werden. Doch schon vor der Zeichnung muss nachvollziehbar sein, wem das Dokument wann angezeigt, wann es genehmigt und wann es signiert wurde. Wo wird das vermerkt, wenn das Ur-Doc selbst unveränderlich bleiben muss?

Das Problem: Events brauchen einen Ort

Die Teile I–III zeigen, wie ein Dokument (Ur-Doc), seine Metadaten (Sidecar), seine Signatur-Docs/Events und der Vorgang (GCPN) zusammenspielen. Ein wunder Punkt bleibt aber offen: Die Events eines einzelnen Dokuments — Anzeige (presented), Genehmigung (accepted), Zeichnung (signed) — brauchen einen eigenen Ort je Dokument, und zwar ab dem Entwurf.

Das Ur-Doc selbst darf diesen Ort nicht tragen. Es ist — sobald es gezeichnet ist — immutable: Jede spätere Änderung (auch eines bloßen Status-Flags) verändert seinen SHA-256 und macht damit eine bereits erfolgte Signatur ungültig. Schon der Entwurf kann die letzte Fassung sein; entsprechend gehört kein Status, keine Historie, kein Prozessvermerk in das Ur-Doc.

Die Lösung: ein Signatur-Artefakt je Dokument (`*.gcsig.md`)

Zu jedem zur Signatur vorgesehenen .md-Ur-Doc gehört ab dem Entwurf ein Signatur-Artefakt {name}.gcsig.md:

V7GUID-Klasse GCSIG, Schema gcsig-1.4. Seit 1.4 kann das GCSIG den Ur-Doc-Inhalt einbetten (content, z. B. business-meal-receipt-1.0 für einen Bewirtungsbeleg), die OCR-Provenienz (ocr, TrustVector-BitVector), den Signatur-Block (signature, mit Facsimile) und einen integrierten Sidecar-Block (source) tragen — damit ersetzt es bei signierten Belegen das separate .v7g.md (siehe unten). 1.3/1.2/1.1/1.0 bleiben gültige Legacy-Schemata.
Mutabler Phasen-Container (wie der GCPN): Der Signatur-Lebenszyklus wird als 32-bit-Phasen-BitVector geführt; Zustandsänderungen sind einfache Bit-Operationen.
Inhalts-Anker: subject.sha = SHA-256 des Ur-Docs. Das Artefakt ist damit an die konkrete Fassung gebunden und history-rewrite-fest.
Bereits im Entwurf (Phase draft) existenzfähig; signer/gpg werden erst zur Signatur gesetzt.

Erzeugung (Werkzeug 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>

Der Phasen-BitVector

Phase	Bit	Wert	Bedeutung
`draft`	0	1	Entwurf (Ausgangspunkt)
`presented`	1	2	zur Zeichnung vorgelegt / angezeigt
`accepted`	2	4	angenommen / genehmigt
`signed`	3	8	signiert
`denied`	4	16	abgelehnt
`withdrawn`	5	32	zurückgezogen
`revoked`	6	64	widerrufen
`expired`	7	128	abgelaufen
`superseded`	8	256	ersetzt
`verified`	9	512	Verifikation erfolgreich (orthogonaler Modifier)

Die Bits kumulieren per OR in phases.phases_result; current_phase wird nach Präzedenz abgeleitet (revoked > superseded > … > draft). verified ist ein orthogonaler Modifier (kein eigener Lebenszyklus-Schritt). Diese Flags-Semantik entspricht der Vorgabe „Events als BitVector" (kein Union-Typ, da kumulativ).

Der Signatur-Block im Ur-Doc

Das Ur-Doc bleibt immutable, erhält aber nach dem Unterschriften-Block einen erklärenden Abschnitt ## Signatur (GCSIG), der das zugehörige Signatur-Artefakt benennt:

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

Die uuidV7 (= docUid des GCSIG) wird zirkelfrei aus der Subjekt-Identität (Dokument-Basisname/Vertrags-ID) abgeleitet — nicht aus dem SHA dieses Dokuments —, damit sie im Ur-Doc stehen darf, ohne den Signatur-Anker instabil zu machen. Ein bloßer Dateiname-Verweis wäre möglich; die zitierte uuidV7 macht das Artefakt aber namentlich identifizierbar und ist — weil identitäts- statt inhaltsbasiert — stabil. Status, Prozess und Events stehen ausschließlich im Signatur-Artefakt und/oder GCPN.

Abgrenzung zu den Nachbarartefakten

Artefakt	Rolle	Mutabilität
Ur-Doc (`{name}.md`)	Quell-Dokument mit Vertragstext + Facsimile	immutable ab Zeichnung
Ur-Doc-Sidecar (`{name}.md.v7g.md`)	Metadaten; SHA-256 = SSoT	mutabel
Signatur-Artefakt (`{name}.gcsig.md`)	Signatur-Lebenszyklus je Dokument, ab Entwurf	mutabel (Phasen-Container)
GCPN (`{name}.gcpn.md`)	Vorgang/Akte; `parents[]`/`children[]`	mutabel
GCSIG (Commit) (`{abbrev}.gcsig.md`)	GPG-signierter Git-Commit	immutable

Das GCSIG als Sidecar — und der Übergang `.v7g.md` → `.gcsig.md`

Das Signatur-Artefakt ist kein bloßes Zusatz-Dokument. Zwei Fälle sind zu unterscheiden:

Sidecar-Funktion (natives MD-Ur-Doc). Liegt das signierte Ur-Doc nativ als Markdown vor — kein Scan, kein PDF, kein Foto —, kann das *.gcsig.md zugleich als Sidecar dienen: Es trägt dann (wie ein .v7g.md) den Inhalts-Anker (SHA-256), den docUid und die Metadaten und den Signatur-Lebenszyklus in einem Artefakt. Ein separates .v7g.md ist dafür nicht zwingend.
Übergang .v7g.md → .gcsig.md (signiertes PDF). Wird ein PDF (o. Ä.) signiert, kann aus dem bisherigen, katalogisierenden .v7g.md ein .gcsig.md werden. Dabei geht keine Information verloren — der Sidecar-Inhalt (Anker, docUid, Klasse, Metadaten) wird in das Signatur-Artefakt überführt. Aber der Status des Ur-Docs und seine Verwendung ändern sich: Aus einem bloß katalogisierten Beleg wird ein signiertes Ur-Doc mit eigenem Signatur-Lebenszyklus (Phasen-BitVector). Es dürfen keine konkurrierenden Sidecars nebeneinander bestehen — der Inhalt wird überführt, nicht dupliziert.

Kurz: Das GCSIG ist die eine Stelle, an der die Signatur dieses Dokuments lebt — ob als reines Signatur-Artefakt, in Sidecar-Rolle oder als Nachfolger eines .v7g.md.

Das Signatur-Artefakt wird vom GCPN über die Tree-Kante (GCSIG:{docUid}) referenziert; umgekehrt nennt es via gcpn_ref seinen Vorgang. Bei Git-Objekten (commit/tree/tag/PR) bleibt das GCSIG dagegen ein immutables Artefakt (gc-docsign gcsig <repo> --commit <sha>).

Regeln (normativ)

Je signaturvorgesehenem Ur-Doc wird ab dem Entwurf ein *.gcsig.md erzeugt (Schema gcsig-1.4); ohne dieses Artefakt sind die Events nicht vermerkbar.
Das Ur-Doc bleibt immutable: kein Status, keine Prozess-/Historien-/ Selbst-Hash-Angaben; nur der ## Signatur (GCSIG)-Block mit Dateinamen-Verweis.
Status/Events leben im Signatur-Artefakt und/oder GCPN.
Ein *.gcsig.md aus einer gc-Signatur (Commit-Signatur) ist ein immutables Ur-Doc; das je-Dokument-Artefakt (document) ist dagegen ein mutabler Phasen-Container.
Bei nativem MD-Ur-Doc kann das *.gcsig.md zugleich Sidecar sein (Metadaten + Lebenszyklus in einem Artefakt). Bei signiertem PDF darf aus dem bisherigen .v7g.md ein .gcsig.md werden — kein Informationsverlust (Inhalt überführen), aber geänderter Ur-Doc-Status/Verwendung; keine konkurrierenden Sidecars.

Querverweise

Teil I — Textform — Ur-Doc, Sidecar, Signatur-Doc, GCPN.
Teil II — FES & Facsimile — FES-Andockung, Facsimile-Layer.
Teil IV — PII, GPG & Governikus — Schlüssel-Ebene.
Werkzeug und Schema: work/OSS/gc-docsign (docs/gcsig.md), Schema gcsig-1.4 (OSS-Normative-Root .gitcover/schemas/).

Erstellt: 261008 | Herausgeber: ORG-1 (Platzhalter) | Serie: digital-signage