DS05 — Le conteneur de signature GCPN : document source, doc FES, opération

Déclencheur S2, conclusion de la partie I

E1 dispose désormais de trois artefacts distincts : le document source (MD), le doc de signature (JSON), les événements (JSON). Le vérificateur demande : Comment cela s'articule-t-il ? La réponse est le conteneur de signature GCPN — une variante du conteneur GitCover PrimaNota (GCPN), qui regroupe tous les artefacts d'une opération de signature sous un identifiant de conteneur.

GCPN — le principe du conteneur

GCPN (GitCover PrimaNota) relie, dans la gestion des pièces justificatives, tous les documents d'une opération commerciale : justificatif original, sidecars, logique d'écriture comptable. Le conteneur de signature transpose ce principe à l'opération de signature :

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)

Le fichier conteneur

Le conteneur lui-même est un document Markdown avec un artefact JSON intégré (comme tous les docs GitCover) :

{
  "$schema": "https://gitcover.org/schemas/gcpn-signature-1.0.schema.json",
  "docUid": "<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.gc.md"
    },
    {
      "role": "signature-doc",
      "kind": "json",
      "location": "260913_signature-doc.json",
      "sha256": "<SHA-256>",
      "sidecar": "260913_signature-doc.json.gc.md"
    },
    {
      "role": "event",
      "kind": "json",
      "events": ["offered", "accepted", "signed"],
      "location": "260913_event-*.json",
      "sha256": "<SHA-256 je Event>",
      "sidecar": "260913_event-*.json.gc.md"
    },
    {
      "role": "facsimile-ref",
      "kind": "ref",
      "file": "E1.Signature.transparent.FES.svg",
      "sha256": "8fcffe0b313f8a1e5b44c1c33cd8073e699b338b6450aa1ba9f33f5587501006",
      "docUid": "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"
  }
}

« D'abord sans prédécesseur/successeur » — le stade de conception

Important pour la qualité de la saga : le conteneur possède les champs prev_container/next_container, mais ils sont null. C'est délibéré — deux étapes de développement :

Étape	prev/next	Signification
Étape 1 (aujourd'hui)	`null`	Le conteneur regroupe entièrement une opération ; aucun chaînage entre conteneurs nécessaire
Étape 2 (prévue)	SHA-256 du conteneur précédent	Chaîne de conteneurs pour procédures à long terme (par ex. cycle de vie du contrat avec avenants)

Les champs existent déjà afin qu'un chaînage ultérieur soit possible sans rupture de schéma. Un conteneur reste immuable — un chaînage crée un nouveau conteneur avec prev_container = sha256(alt).

Le conteneur en trois rôles

Artefact	Rôle dans le conteneur	Valeur probante
Document source	Le contenu à signer	Intégrité de la version (SHA-256)
Doc de signature FES	La déclaration de volonté (forme textuelle ou FES)	Attribution de l'origine (§ 371a ZPO)
Événements Accept/Deny/Sign	Le processus déterministe	Équité de la procédure, chronologie
Référence Facsimile	Le dessin comme référence graphique	Marquage visible (§ 126b (3))
Sortie FES (PDF)	La version FES physique	Uniquement pour les procédures FES — physiquement incluse dans le paquet conteneur

Sortie HTML et paquet conteneur

En cas de sortie HTML (site web GCBoK, aperçu), le conteneur est livré physiquement sous forme de paquet :

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

Le paquet est auto-vérifiant : le vérificateur le décompresse et exécute la routine de DS04 — sans accès au dépôt, sans Git.

Résumé

Le conteneur de signature GCPN regroupe tous les artefacts d'une opération de signature sous un identifiant de conteneur avec manifeste de vérification.
prev_container/next_container sont préparés (fixés par le schéma), mais initialement null — le chaînage est l'étape 2.
Le doc FES est référencé ; la version FES physique (PDF) se trouve dans le paquet conteneur (partie II).
La partie I se termine ici. La partie II raccorde la FES : bases eIDAS, graphique Facsimile dans la couche PDF, rapport d'enveloppe, paquet conteneur.

Créé : 260913 | Partie I, article DS05 | Série : digital-signage