Parte VI — Documentos firmados con Git: el artefacto de firma (GCSIG)

Desencadenante S6: Un contrato debe firmarse de forma nativa con Git. Pero ya antes de la firma debe ser trazable a quién se le mostró el documento, cuándo se aprobó y cuándo se firmó. ¿Dónde se registra esto si el documento original mismo debe permanecer inmutable?

El problema: los eventos necesitan un lugar

Las partes I–III muestran cómo interactúan un documento (documento original), sus metadatos (Sidecar), sus documentos de firma/eventos y el expediente (GCPN). Sin embargo, queda abierto un punto central: los eventos de un documento individual — visualización (presented), aprobación (accepted), firma (signed) — necesitan un lugar propio por documento, y ello desde el borrador.

El documento original mismo no puede llevar ese lugar. Es —una vez firmado— inmutable: cualquier cambio posterior (incluso de un mero flag de estado) altera su SHA-256 e invalida una firma ya realizada. Ya el borrador puede ser la última versión; en consecuencia, ningún estado, ningún historial, ninguna nota de proceso pertenece al documento original.

La solución: un artefacto de firma por documento (`*.gcsig.md`)

A cada documento original .md previsto para firma le corresponde, desde el borrador, un artefacto de firma {name}.gcsig.md:

Clase V7GUID GCSIG, esquema gcsig-1.4. Desde 1.4, el GCSIG puede incorporar el contenido del documento original (content, p. ej. business-meal-receipt-1.0 para un comprobante de restauración), la procedencia OCR (ocr, vector de bits TrustVector), el bloque de firma (signature, con facsímil) y un bloque Sidecar integrado (source); con ello sustituye, en comprobantes firmados, al .v7g.md separado (véase más abajo). 1.3/1.2/1.1/1.0 siguen siendo esquemas legacy válidos.
Contenedor de fases mutable (como el GCPN): el ciclo de vida de firma se lleva como vector de bits de fases de 32 bits; los cambios de estado son simples operaciones de bits.
Ancla de contenido: subject.sha = SHA-256 del documento original. El artefacto queda así vinculado a la versión concreta y es resistente a la reescritura del historial.
Puede existir ya en el borrador (fase draft); signer/gpg se establecen solo al firmar.

Creación (herramienta gc-docsign):

gc-docsign gcsig --doc "<ur-doc.md>"            # ab Entwurf, Phase draft
gc-docsign gcsig --doc "<ur-doc.md>" --phase presented
gc-docsign gcsig --doc "<ur-doc.md>" --phase accepted
gc-docsign gcsig --doc "<ur-doc.md>" --phase signed --key <fingerprint>

El vector de bits de fases

Fase	Bit	Valor	Significado
`draft`	0	1	Borrador (punto de partida)
`presented`	1	2	presentado / mostrado para firma
`accepted`	2	4	aceptado / aprobado
`signed`	3	8	firmado
`denied`	4	16	rechazado
`withdrawn`	5	32	retirado
`revoked`	6	64	revocado
`expired`	7	128	caducado
`superseded`	8	256	reemplazado
`verified`	9	512	verificación exitosa (modificador ortogonal)

Los bits se acumulan mediante OR en phases.phases_result; current_phase se deriva por precedencia (revoked > superseded > … > draft). verified es un modificador ortogonal (no un paso propio del ciclo de vida). Esta semántica de flags corresponde a la especificación «Eventos como BitVector» (sin tipo unión, ya que es acumulativa).

El bloque de firma en el documento original

El documento original permanece inmutable, pero después del bloque de firmas recibe una sección explicativa ## Signatur (GCSIG) que nombra el artefacto de firma correspondiente:

## Signatur (GCSIG)

Diese Vereinbarung ist für **GC-Signatur** erstellt. …

- **Signatur-Artefakt (GCSIG):** `<uuidV7>`      ← der „Name" (docUid)
- **Titel:** `<basename>.gcsig.md`               ← Dateiname
- **Verfahren:** Textform (§ 126b BGB) mit Facsimile; GC-Signatur (GPG / signierter Git-Commit)
- **Zeichner:** <Name> (Rolle)

La uuidV7 (= docUid del GCSIG) se deriva sin ciclos de la identidad del sujeto (nombre base del documento/ID del contrato) — no del SHA de este documento —, para que pueda figurar en el documento original sin volver inestable el ancla de firma. Una mera referencia al nombre de archivo sería posible; sin embargo, la uuidV7 citada hace que el artefacto sea identificable por nombre y es —por basarse en la identidad en lugar del contenido— estable. El estado, el proceso y los eventos se encuentran exclusivamente en el artefacto de firma y/o GCPN.

Delimitación con los artefactos vecinos

Artefacto	Rol	Mutabilidad
Documento original (`{name}.md`)	Documento fuente con texto del contrato + facsímil	inmutable desde la firma
Sidecar del documento original (`{name}.md.v7g.md`)	Metadatos; SHA-256 = SSoT	mutable
Artefacto de firma (`{name}.gcsig.md`)	Ciclo de vida de firma por documento, desde el borrador	mutable (contenedor de fases)
GCPN (`{name}.gcpn.md`)	Expediente/acta; `parents[]`/`children[]`	mutable
GCSIG (Commit) (`{abbrev}.gcsig.md`)	Commit de Git firmado con GPG	inmutable

El GCSIG como Sidecar — y la transición `.v7g.md` → `.gcsig.md`

El artefacto de firma no es un mero documento adicional. Hay que distinguir dos casos:

Función de Sidecar (documento original MD nativo). Si el documento original firmado está disponible de forma nativa como Markdown —sin escaneo, sin PDF, sin foto—, el *.gcsig.md puede servir al mismo tiempo como Sidecar: entonces lleva (como un .v7g.md) el ancla de contenido (SHA-256), el docUid y los metadatos y el ciclo de vida de firma en un solo artefacto. Un .v7g.md separado no es obligatorio para ello.
Transición .v7g.md → .gcsig.md (PDF firmado). Si se firma un PDF (o similar), el .v7g.md anterior, que catalogaba, puede convertirse en un .gcsig.md. No se pierde información: el contenido del Sidecar (ancla, docUid, clase, metadatos) se traslada al artefacto de firma. Pero el estado del documento original y su uso cambian: un comprobante meramente catalogado se convierte en un documento original firmado con su propio ciclo de vida de firma (vector de bits de fases). No deben existir Sidecars competidores en paralelo; el contenido se traslada, no se duplica.

En resumen: el GCSIG es el único lugar donde vive la firma de este documento —ya sea como artefacto de firma puro, en rol de Sidecar o como sucesor de un .v7g.md.

El GCPN referencia el artefacto de firma mediante la arista de árbol (GCSIG:{docUid}); a la inversa, este menciona su expediente mediante gcpn_ref. En cambio, en objetos de Git (commit/tree/tag/PR), el GCSIG sigue siendo un artefacto inmutable (gc-docsign gcsig <repo> --commit <sha>).

Reglas (normativas)

Por cada documento original previsto para firma se crea, desde el borrador, un *.gcsig.md (esquema gcsig-1.4); sin este artefacto, los eventos no pueden registrarse.
El documento original permanece inmutable: sin estado, sin indicaciones de proceso/historial/ hash propio; solo el bloque ## Signatur (GCSIG) con referencia al nombre de archivo.
Estado/eventos viven en el artefacto de firma y/o GCPN.
Un *.gcsig.md procedente de una gc-Signatur (firma de commit) es un documento original inmutable; el artefacto por documento (document) es, en cambio, un contenedor de fases mutable.
En un documento original MD nativo, el *.gcsig.md puede ser al mismo tiempo Sidecar (metadatos + ciclo de vida en un solo artefacto). En un PDF firmado, el .v7g.md anterior puede convertirse en un .gcsig.md: sin pérdida de información (trasladar el contenido), pero con estado/uso del documento original modificados; sin Sidecars competidores.

Referencias cruzadas

Parte I — Forma textual — documento original, Sidecar, documento de firma, GCPN.
Parte II — FES y facsímil — acoplamiento FES, capa de facsímil.
Parte IV — PII, GPG y Governikus — nivel de claves.
Herramienta y esquema: work/OSS/gc-docsign (docs/gcsig.md), esquema gcsig-1.4 (raíz normativa OSS .gitcover/schemas/).

Creado: 261008 | Editor: ORG-1 (marcador de posición) | Serie: digital-signage