DS05 — Der GCPN-Signatur-Container: Quell-Dokument, FES-Doc, Vorgang

Auslöser S2, Abschluss von Teil I

E1 hat nun drei getrennte Artefakte: das Quell-Dokument (MD), den Signatur-Doc (JSON), die Events (JSON). Der Prüfer fragt: Wie hängt das zusammen? Die Antwort ist der GCPN-Signatur-Container — eine Variante des GitCover-PrimaNota-Containers (GCPN), die alle Artefakte eines Signatur-Vorgangs unter einer Container-ID bündelt.

GCPN — das Container-Prinzip

GCPN (GitCover PrimaNota) verbindet im Belegwesen alle Dokumente eines Geschäftsvorgangs: Originalbeleg, Sidecars, Buchungslogik. Der Signatur-Container überträgt das Prinzip auf den Signatur-Vorgang:

GCPN-Container (sign)
   ├── Quell-Dokument (MD) + Sidecar
   ├── FES-Signatur-Doc (JSON) + Sidecar        ← referenziert
   ├── FES-Output (PDF/HTML, physisch)          ← nur bei FES-Verfahren
   ├── Events (offered/accepted/signed) + Sidecar
   ├── Facsimile-Grafik-Verweis (SHA-256 + guid-Stempel)
   └── Verifikationsmanifest (SHA-256 aller Glieder)

Die Container-Datei

Der Container selbst ist ein Markdown-Dokument mit eingebettetem JSON-Artefakt (wie alle GitCover-Docs):

{
  "$schema": "https://gitcover.org/schemas/gcpn-signature-1.0.schema.json",
  "uuidV7": "<deterministische uuidV7>",
  "type": "gcpn-signature",
  "kind": "signature-process",
  "container_id": "GCPN-SIG-260913-001",
  "scope": {
    "tenant": "GCC",
    "entity": "ORG-1",
    "matter": "[GVB](../../glossar.html#gvb "Gesellschafterversammlungsbeschluss — Glossar") 260825 — GF-Vertrag: Selbständigkeit, Ehrenamt",
    "sphere": "wirtschaftlich"
  },
  "artifacts": [
    {
      "role": "source",
      "kind": "markdown",
      "location": "..\\260825-shareholder-meeting-resolution.md",
      "sha256": "<SHA-256>",
      "sidecar": "..\\260825_*.md.v7g.md"
    },
    {
      "role": "signature-doc",
      "kind": "json",
      "location": "260913_signature-doc.json",
      "sha256": "<SHA-256>",
      "sidecar": "260913_signature-doc.json.v7g.md"
    },
    {
      "role": "event",
      "kind": "json",
      "events": ["offered", "accepted", "signed"],
      "location": "260913_event-*.json",
      "sha256": "<SHA-256 je Event>",
      "sidecar": "260913_event-*.json.v7g.md"
    },
    {
      "role": "facsimile-ref",
      "kind": "ref",
      "file": "E1.Signature.transparent.FES.svg",
      "sha256": "8fcffe0b313f8a1e5b44c1c33cd8073e699b338b6450aa1ba9f33f5587501006",
      "guid_stamp": "01a09b48-4580-76f9-b789-024691b989c5",
      "note": "Verweis, nicht Einbettung — Grafik liegt im [PII](../../glossar.html#pii "Personally Identifiable Information — Glossar")-Verzeichnis"
    },
    {
      "role": "fes-doc",
      "kind": "pdf",
      "location": "260913_FES_Envelope-Report.pdf",
      "sha256": "<SHA-256>",
      "note": "Nur bei FES-Verfahren — physisch im Container-Paket (Teil II)"
    }
  ],
  "prev_container": null,
  "next_container": null,
  "verification": {
    "method": "sha256 + jq routine (DS04)",
    "verified_at": "2026-09-13T16:00:00Z",
    "verified_by": "E1"
  }
}

"Zunächst ohne Vorgänger/Nachfolger" — das Design-Stadium

Wichtig für die Saga-Qualität: Der Container hat die Felder prev_container/next_container, aber sie sind null. Das ist bewusst — zwei Entwicklungsstufen:

Die Felder existieren bereits, damit eine spätere Verkettung ohne Schema-Bruch möglich ist. Ein Container bleibt unveränderlich — eine Verkettung erzeugt einen neuen Container mit prev_container = sha256(alt).

Der Container in drei Rollen

HTML-Output und das Container-Paket

Bei HTML-Output (GCBoK-Website, Preview) wird der Container physisch als Paket ausgeliefert:

<container-id>.gcpn.zip
   ├── container.md              (dieser Container)
   ├── source.md + .v7g.md
   ├── signature-doc.json + .v7g.md
   ├── event-*.json + .v7g.md
   ├── facsimile.svg             (bei FES: physisch, sonst Verweis)
   └── fes-envelope-report.pdf   (nur bei FES)

Das Paket ist selbst-verifizierend: Der Prüfer entpackt es und führt die Routine aus DS04 aus — ohne Repo-Zugriff, ohne Git.

Zusammenfassung

• Der GCPN-Signatur-Container bündelt alle Artefakte eines Signatur-Vorgangs unter einer Container-ID mit Verifikationsmanifest.
• prev_container/next_container sind vorbereitet (Schema-fest), aber zunächst null — Verkettung ist Stufe 2.
• Der FES-Doc wird referenziert; die physische FES-Fassung (PDF) liegt im Container-Paket (Teil II).
• Teil I schließt hier. Teil II dockt die FES an: eIDAS-Grundlagen, Facsimile-Grafik im PDF-Layer, Envelope-Report, Container-Paket.

---

Erstellt: 260913 | Teil I, Artikel DS05 | Serie: digital-signage