DS10 — Das FES-Container-Paket (gcpn.zip)

Auslöser S4, Abschluss von Teil II

Der Prüfer (oder Geschäftspartner) will die Kette sehen — nicht nur zusammengefasst. Er erhält kein Repo, keinen Git-Zugang, keine Historie. Er erhält ein Paket: *.gcpn.zip — das physische Verifikations-Set des Signatur-Vorgangs.

Manifest und ZIP-Archiv — zwei getrennte Aufgaben

Aufgabe	Träger	Inhalt
Manifest	die `.gcpn.md` selbst	Führt alle Artefakte mit SHA-256 auf (Verifikationstabelle + eingebettete JSON-Artefakte) — sie identifiziert, was zum Vorgang gehört
ZIP-Archiv	`*.gcpn.zip`	Die physischen Dateien zur Auslieferung: die textbasierten Artefakte (aus der `.gcpn.md` als `.json`/`.txt`/`.md`/`.v7g.md` extrahiert) plus die binären Artefakte als separate Files

Textbasierte Artefakte (.json, .txt, .md, .v7g.md) leben in der .gcpn.md (MD-Fences) — im ZIP werden sie als Einzeldateien gezeigt (extrahierbar). Binäre Artefakte (PDF, PNG, SVG, …) können nicht in der MD-Datei leben — sie werden als separate Files ins ZIP aufgenommen; in aller Regel sind sie bereits in den JSON-Artefakt-Datenstrukturen referenziert bzw. als SHA-256-Hash identifiziert (z. B. evidence.facsimile_ref.sha256) — der Hash ist die Identifikation, das ZIP liefert den Körper.

Die Paket-Struktur

GCPN-SIG-260913-001.gcpn.zip
│
├── container.gcpn.md                      ← Manifest + textbasierte Artefakte (JSON-Fences) + .v7g.md
│                                            (identisch mit der Form im Git-Repo)
├── MANIFEST.json                          ← maschinen-lesbares Verzeichnis (alle SHA-256, package_sha256)
│
├── source/                                ← textbasiert: Quell-Dokument, aus dem Container extrahierbar
│   ├── gvb.md                             ← Quell-Dokument (referenced_doc)
│   └── gvb.md.v7g.md                      ← Sidecar
├── signature/                             ← textbasiert: Signatur-Doc + Events (aus MD-Fences)
│   ├── signature-doc.json                 ← Signatur-Doc (DS02) + .v7g.md
│   ├── event-offered.json                 ← Events (DS03) + .v7g.md
│   ├── event-accepted.json
│   ├── event-signed.json
│   ├── facsimile.svg                      ← BINÄR: Grafik physisch (Standard) — im JSON nur als SHA-256 referenziert
│   ├── facsimile.png                      ← BINÄR: Fallback
│   └── facsimile.sha256                   ← Checksums
├── fes/                                   ← binäre FES-Artefakte
│   ├── fes-envelope-report.json           ← Envelope-Report (DS09) + .v7g.md (textbasiert)
│   ├── contract-signed.pdf                ← BINÄR: signiertes PDF (PAdES)
│   ├── certificate-of-completion.pdf      ← BINÄR: Dienst-Report
│   └── pdfsig-report.txt                  ← Krypto-Prüfung (externes Tool)
└── README.md                              ← Verifikations-Anleitung (DS04-Routine)

Lesart: Das Manifest (.gcpn.md) nennt jedes Artefakt mit SHA-256 — das ZIP liefert die Körper dazu. Textbasierte Artefakte sind im Manifest selbst enthalten (und im ZIP zusätzlich als Einzeldateien extrahiert); binäre Artefakte sind nur im ZIP physisch vorhanden, im Manifest jedoch vollständig durch ihren SHA-256 identifiziert. Ein Prüfer kann also jeden Körper gegen die Hash-Angabe im Manifest verifizieren.

Das Verifikationsmanifest

MANIFEST.json bündelt alle SHA-256 des Pakets:

{
  "$schema": "https://gitcover.org/schemas/gcpn-manifest-1.0.schema.json",
  "uuidV7": "<deterministische uuidV7>",
  "package": "GCPN-SIG-260913-001",
  "created_at": "2026-09-13T16:45:00Z",
  "created_by": "E1",
  "artifacts": [
    {"path": "container.md", "sha256": "…"},
    {"path": "source/gvb.md", "sha256": "…"},
    {"path": "signature/signature-doc.json", "sha256": "…"},
    {"path": "signature/event-offered.json", "sha256": "…"},
    {"path": "signature/event-accepted.json", "sha256": "…"},
    {"path": "signature/event-signed.json", "sha256": "…"},
    {"path": "signature/facsimile.svg", "sha256": "8fcffe0b…1006"},
    {"path": "signature/facsimile.png", "sha256": "d330348e…81fef"},
    {"path": "fes/fes-envelope-report.json", "sha256": "…"},
    {"path": "fes/contract-signed.pdf", "sha256": "7a054fa5…272b"}
  ],
  "verification_routine": "siehe README.md (DS04-Routine)",
  "package_sha256": "<SHA-256 des ZIP selbst>"
}

Die Facsimile-Regel: physisch bei FES, Verweis sonst

Wichtig (Saga-Kernregel):

Verfahren	Facsimile im Paket	Begründung
Textform (Teil I)	Verweis (SHA-256 + guid-Stempel)	Grafik liegt im PII-Verzeichnis des Tenant-Repos; die Kette verweist, das Paket dokumentiert den Verweis
FES (Teil II)	Physisch (SVG + PNG)	Das Paket ist die vollständige Auslieferung; der Prüfer braucht die Grafik zur Prüfung, ohne Repo-Zugriff

Der Unterschied ist bewusst: Bei Textform bleibt das Asset dort, wo es GoBD-relevant gepflegt wird (PII-Verzeichnis, Sidecar, SHA-Verifikation); bei FES wird es kopiert — das Paket ist die vollständige Fassung (Originale bleiben unverändert im Repo; SHA-256 beweist Identität).

Die Verifikationsroutine im Paket

README.md führt den Prüfer durch die Routine (DS04, paket-nativ):

# 1. Manifest-Integrität
sha256sum -c <(jq -r '.artifacts[] | "\(.sha256)  \(.path)"' MANIFEST.json)
# 2. Kette prüfen (Quell-Dokument → Signatur-Doc → Events)
jq -r '.target.sha256' signature/signature-doc.json   # = sha256(source/gvb.md)
# 3. Event-Kette
jq -r '.prev_event_sha256' signature/event-*.json     # Verkettung prüfen
# 4. Facsimile
sha256sum signature/facsimile.svg                     # = 8fcffe0b…1006 (Tabelle)
# 5. PDF-Signatur (externes Tool, optional)
pdfsig fes/contract-signed.pdf                        # VALID, PAdES-B-T

Export-ZIP vs. Git-Repo: Manifest-Definition

Zwei Darstellungsformen desselben Containers:

Form	Name	Rolle
Im Git-Repo	`<Referenced-Doc-Basisname>.gcpn.md`	Der Container selbst — seine eingebetteten JSON-Artefakte + Verifikationstabelle sind das Manifest (das Repo zeigt den Inhalt direkt; ZIP-Dateien sind in Git nicht darstellbar)
Als Export	`<Referenced-Doc-Basisname>.gcpn.zip`	Physische Auslieferung (ZIP) — zusätzlich mit `MANIFEST.json` (alle SHA-256 + `package_sha256`) als Maschinen-lesbares Verzeichnis

Ist die Manifest-Definition damit gültig? Ja — in beiden Formen: Im Git-Repo erfüllt die .gcpn.md die Manifest-Funktion (sie führt jedes Artefakt mit SHA-256 auf, die Verifikationsroutine prüft gegen die eingebetteten Angaben); im Export-ZIP wird dieselbe Manifest-Funktion als MANIFEST.json zusätzlich physisch beigelegt, damit der Empfänger ohne MD-Parser prüfen kann (sha256sum -c). Beide Formen sind äquivalent — der SHA-256 der enthaltenen Artefakte ist die Identifikation (immer und überall).

Suffix	Bedeutung
`.gcpn`	GitCover-PrimaNota-Container (Geschäftsvorhaben gebündelt)
`.md`	Markdown-basiert (JSON-Artefakte in MD-Fences, Typora-kompatibel) — Manifest-Funktion im Repo
`.zip`	Export-Form (physische Auslieferung, `MANIFEST.json` beigefügt)

Die Saga schließt Teil II

Der Kreis ist geschlossen:

Teil I: Textform-Kette (Quell-Dokument, Signatur-Doc, Events, Sidecars, GCPN-Container) — § 126b BGB, freie Beweiswürdigung.
Teil II: FES-Andock (eIDAS-Stufen, Facsimile-Layer, Signaturplatte, Envelope-Report, physisches Paket).
Teil III (geplant): PII/GPG-Kreis — Schlüssel-Verwaltung, Signing-Identity-JSON-Schemas, SSH-vs.-OpenPGP-Mechanik, Trust-Registry.

Die Saga zeigt: GitCover ersetzt Signaturdienste nicht — es verankert sie. Das Repo bleibt die Nachweis-Ebene; externe Verfahren docken an, ohne die Kette zu brechen.

Erstellt: 260913 | Teil II, Artikel DS10 | Serie: digital-signage