DS05 — Le conteneur de signature GCPN : document source, FES-Doc, procédure

Déclencheur S2, conclusion de la partie I

E1 dispose désormais de trois artefacts distincts : le document source (MD), le Signatur-Doc (JSON), les events (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 procédure de signature sous une Container-ID.

GCPN — le principe du conteneur

GCPN (GitCover PrimaNota) relie, dans la gestion des pièces justificatives, tous les documents d'une opération commerciale : pièce originale, sidecars, logique de comptabilisation. Le conteneur de signature transpose ce principe à la procédure 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 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"
  }
}

« Initialement sans prédécesseur/successeur » — le stade de conception

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

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 conteneur nouveau avec prev_container = sha256(alt).

Le conteneur dans trois rôles

Sortie HTML et paquet du conteneur

Pour une sortie HTML (site GCBoK, Preview), le conteneur est livré physiquement sous forme de paquet :

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

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

Résumé

• Le conteneur de signature GCPN regroupe tous les artefacts d'une procédure de signature sous une Container-ID avec manifeste de vérification.
• prev_container/next_container sont prévus (figés dans le schéma), mais pour l'instant null — le chaînage est le niveau 2.
• Le FES-Doc est référencé ; la version FES physique (PDF) se trouve dans le paquet du conteneur (partie II).
• La partie I se conclut ici. La partie II arrime la FES : fondamentaux eIDAS, graphique Facsimile dans la couche PDF, Envelope-Report, paquet du conteneur.

---

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