DS05 — El contenedor de firma GCPN: documento fuente, Doc de FES, expediente

Desencadenante S2, cierre de la Parte I

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

GCPN — el principio del contenedor

GCPN (GitCover PrimaNota) conecta en el ámbito de los comprobantes todos los documentos de un proceso de negocio: comprobante original, sidecars, lógica de contabilización. El contenedor de firma traslada este principio al proceso 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 en sí es un documento Markdown con un artefacto JSON incrustado (como todos los docs de GitCover):

{
  "$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"
  }
}

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

Importante para la calidad de saga: el contenedor tiene los campos prev_container/next_container, pero están en null. Esto es deliberado — dos etapas de desarrollo:

Etapa	prev/next	Significado
Etapa 1 (hoy)	`null`	El contenedor agrupa un expediente por completo; no se necesita encadenamiento entre contenedores
Etapa 2 (prevista)	SHA-256 del contenedor predecesor	Cadena de contenedores para procedimientos de larga duración (p. ej., ciclo de vida de contratos con novaciones)

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

El contenedor en tres roles

Artefacto	Rol en el contenedor	Valor probatorio
Documento fuente	El contenido a firmar	Integridad de la versión (SHA-256)
Doc de firma FES	La declaración de voluntad (forma textual o FES)	Atribución de origen (§ 371a ZPO)
Accept/Deny/Sign-Events	El proceso determinista	Equidad del procedimiento, cronología
Referencia de Facsimile	El dibujo como referencia gráfica	Identificación reconocible (§ 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

Con salida HTML (sitio web GCBoK, Preview), el contenedor se entrega físicamente como paquete:

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

El paquete es autoverificable: el examinador 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 proceso de firma bajo un 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 Doc de 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 acopla la FES: fundamentos de eIDAS, gráfico Facsimile en la capa PDF, Envelope-Report, paquete del contenedor.

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