DS05 — El contenedor de firma GCPN: documento de origen, documento FES, procedimiento

Disparador S2, cierre de la Parte I

E1 tiene ahora tres artefactos separados: el documento de origen (MD), el documento de firma (JSON) y los eventos (JSON). El verificador pregunta: ¿Cómo se relaciona esto? La respuesta es el contenedor de firma GCPN — una variante del contenedor GitCover-PrimaNota (GCPN) que agrupa todos los artefactos de un procedimiento de firma bajo una ID de contenedor.

GCPN — el principio del contenedor

GCPN (GitCover PrimaNota) conecta en la documentación de comprobantes todos los documentos de una operación comercial: comprobante original, sidecars, lógica de contabilización. El contenedor de firma traslada el principio al procedimiento de firma:

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)

El archivo del contenedor

El contenedor mismo es un documento Markdown con un artefacto JSON incrustado (como todos los documentos 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"
  }
}

"Inicialmente sin predecesor/sucesor" — la fase de diseño

Importante para la calidad de la saga: el contenedor tiene los campos prev_container/next_container, pero son null. Esto es intencional — dos etapas de desarrollo:

Etapa	prev/next	Significado
Etapa 1 (hoy)	`null`	El contenedor agrupa un procedimiento por completo; no se necesita encadenamiento entre contenedores
Etapa 2 (prevista)	SHA-256 del contenedor predecesor	Cadena de contenedores para procedimientos a largo plazo (p. ej., ciclo de vida contractual con modificaciones)

Los campos ya existen para que un encadenamiento posterior sea posible sin ruptura del esquema. Un contenedor permanece inmutable — un encadenamiento crea un nuevo contenedor con prev_container = sha256(alt).

El contenedor en tres roles

Artefacto	Rol en el contenedor	Valor probatorio
Documento de origen	El contenido que se va a firmar	Integridad de la versión (SHA-256)
Documento de firma FES	La declaración de voluntad (forma textual o FES)	Atribución de origen (§ 371a ZPO)
Eventos Accept/Deny/Sign	El procedimiento determinista	Equidad del procedimiento, cronología
Referencia Facsimile	El dibujo como referencia gráfica	Identificación visible (§ 126b (3))
Salida FES (PDF)	La versión física FES	Solo en procedimientos FES — incluida físicamente en el paquete del contenedor

Salida HTML y el paquete del contenedor

En la salida HTML (sitio web de GCBoK, vista previa), el contenedor se entrega físicamente como paquete:

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

El paquete es autoverificable: el verificador lo descomprime y ejecuta la rutina de DS04 — sin acceso al repositorio, sin Git.

Resumen

El contenedor de firma GCPN agrupa todos los artefactos de un procedimiento de firma bajo una ID de contenedor con manifiesto de verificación.
prev_container/next_container están preparados (fijados en el esquema), pero inicialmente null — el encadenamiento es la Etapa 2.
El documento FES se referencia; la versión física FES (PDF) se encuentra en el paquete del contenedor (Parte II).
La Parte I concluye aquí. La Parte II conecta la FES: fundamentos de eIDAS, gráfico facsímil en la capa PDF, Envelope-Report, paquete del contenedor.

Creado: 260913 | Parte I, artículo DS05 | Serie: digital-signage