DS02 — El Doc de firma como tipo de dato (JSON-Schema)

Desencadenante S1, continuación

E1 ha adoptado una resolución (GVB) en Markdown. Ahora necesita un artefacto que deje constancia de forma reconocible: Yo, E1, firmo este documento en la fecha X en mi calidad de Y. El artefacto debe ser legible por máquina, validado por esquema y apto para auditoría — un artefacto JSON según la regla 1 de GCBoK ("JSON-First") y la regla 4 ("Schema-First").

El tipo de dato `signature-1.0`

El JSON-Schema define una firma como documento independiente en el repo — no como anexo, no como texto de correo. Estructura central (simplificada):

{
  "$schema": "https://gitcover.org/schemas/signature-1.0.schema.json",
  "uuidV7": "<deterministische uuidV7 aus ts+doc-sha256>",
  "type": "signature",
  "subject": {
    "name": "Erich Mustermann",
    "role": "Geschäftsführer",
    "capacity": "handelnd unter Befreiung von § 181 BGB",
    "entity": "PARTNER-ORG"
  },
  "target": {
    "kind": "gvb",
    "title": "GVB 260825 — GF-Vertrag: Selbständigkeit",
    "sha256": "<sha256 des Quell-Dokuments>",
    "location": "\\\\vm1\\data\\org1\\repo-top\\res\\260825-shareholder-meeting-resolution.md"
  },
  "procedure": {
    "form": "textform",
    "statute": "§ 126b BGB",
    "legal_basis_ref": "GVB 260825, TOP 'Beschlussfassung in Textform'",
    "expression": "Abgabe der Erklärung in elektronischer Form (§ 371a ZPO)"
  },
  "evidence": {
    "facsimile_ref": {
      "file": "E1.Signature.transparent.FES.svg",
      "sha256": "8fcffe0b313f8a1e5b44c1c33cd8073e699b338b6450aa1ba9f33f5587501006",
      "guid_stamp": "01a09b48-4580-76f9-b789-024691b989c5"
    },
    "timestamp_utc": "2026-09-13T15:00:00Z",
    "timestamp_source": "uuidV7-RFC9562"
  }
}

Los campos obligatorios en detalle

Grupo de campos	Obligatorio	Propósito
`uuidV7`	sí	ID determinista a partir de marca de tiempo + doc-sha256 (gen-doc) — sello guid para "accepted"/"signed"
`subject`	sí	Firmante: nombre, rol, poder de representación, corporación
`target`	sí	Documento fuente: título, SHA-256, ruta UNC — la firma se ancla a una versión concreta
`procedure`	sí	Procedimiento: textform/FES, norma jurídica, indicación de forma (§ 371a ZPO)
`evidence`	sí	Referencia al Facsimile (SHA-256 + sello guid del gráfico de firma), marca de tiempo
`signing_key_ref`	opcional	Solo en la Parte III (círculo PII/GPG) — referencia de clave, no en las Partes I/II

Regla Schema-First: antes de cada registro, comprobar si existe un esquema; si falta, se crea. El Doc de firma sigue el mismo patrón que diary-entry, v7g-sidecar y los contenedores GCPN.

Catalogización V7GUID

El Doc de firma recibe una V7GUID-Class-Taxonomy propia en el sidecar (similar a SIGNATURE_GRAPHIC para los recursos gráficos):

Class	Uso
`SIGNATURE_DOC`	El propio Doc de firma (artefacto JSON)
`SIGNATURE_GRAPHIC`	El gráfico Facsimile (PNG/SVG) — ya registrado el 260913
`SIGNATURE_EVENT`	El proceso de firma (Accept/Deny/Sign) — DS03

Cada clase es un candidato a promoción para el OSS-Normative-Root (work/OSS/TOP/.gitcover/dictionaries/classes.json), análogo al piloto de 260821 (HR_REGISTER_DOC, RECEIPT_DOC etc.).

Por qué la firma es un documento propio

Tres decisiones de diseño que impulsan la saga:

Separación entre contenido y declaración de voluntad — el documento fuente permanece inalterado (Immutable-Doc); la firma es un artefacto separado que se ancla mediante SHA-256 a la versión concreta. Un error tipográfico en el documento fuente no invalida la capa de firma; una nueva versión genera una nueva firma.
Firma múltiple — varios firmantes generan varios Docs de firma sobre el mismo documento fuente (p. ej., GVB con dos líneas de firma). La verificación comprueba todos los Docs de firma contra la misma SHA del documento fuente.
Acoplabilidad FES — la firma FES (Parte II) no sustituye al Doc de firma, sino que lo complementa: el Doc de firma permanece como la capa del repo, y el FES-Doc (Envelope-Report, PDF) se referencia como un artefacto adicional.

Referencia Facsimile (no incrustación)

Importante para la calidad de la saga: el Doc de firma no incrusta físicamente el gráfico de firma. Remite a él — mediante SHA-256 y sello guid (E1.Signature.transparent.FES.svg, sha256 8fcffe0b…, guid 01a09b48-4580-76f9-b789-024691b989c5). Esto hace que la cadena sea ligera: el gráfico, el documento fuente y el Doc de firma son verificables de forma independiente; el valor probatorio reside en la verificación, no en la incrustación.

La incrustación física (Facsimile en la capa PDF, al estilo DocuSign) corresponde a la Parte II — allí donde la firma FES genera un PDF-Doc propio.

Resumen

El Doc de firma es un artefacto JSON (esquema signature-1.0) con los campos obligatorios subject, target, procedure, evidence.
Se ancla mediante SHA-256 a una versión concreta del documento fuente.
El gráfico Facsimile se referencia (SHA-256 + sello guid), no se incrusta — la incrustación es material FES (Parte II).
Próximo artículo (DS03): el proceso de firma como evento.

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