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

Disparador 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, cuándo se aprobó y cuándo se firmó. ¿Dónde se registra eso si el propio Ur-Doc debe permanecer inalterable?

El problema: los eventos necesitan un lugar

Las partes I–III muestran cómo interactúan un documento (Ur-Doc), sus metadatos (Sidecar), sus Signatur-Docs/eventos y el procedimiento (GCPN). Pero queda abierto un punto delicado: los eventos de un documento individual —presentación (presented), aprobación (accepted), firma (signed)— necesitan un lugar propio por documento, y ello desde el borrador.

El propio Ur-Doc no puede albergar ese lugar. Una vez firmado, es inmutable: cualquier cambio posterior (incluso el de un mero flag de estado) altera su SHA-256 y con ello invalida una firma ya realizada. Ya el borrador puede ser la última versión; en consecuencia, ningún estado, ningún historial, ninguna anotación de proceso debe ir en el Ur-Doc.

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

A cada Ur-Doc .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 Ur-Doc (content, p. ej. business-meal-receipt-1.0 para un justificante de gastos de restauración), la procedencia OCR (ocr, BitVector de TrustVector), el bloque de firma (signature, con facsímil) y un bloque Sidecar integrado (source) — con ello sustituye, en justificantes firmados, al .gc.md separado (véase 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 gestiona como BitVector de fases de 32 bits; los cambios de estado son simples operaciones de bits.
Ancla de contenido: subject.sha = SHA-256 del Ur-Doc. El artefacto queda así vinculado a la versión concreta y es resistente a la reescritura de historial.
Puede existir ya en el borrador (fase draft); signer/gpg solo se establecen 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 BitVector de fases

Fase	Bit	Valor	Significado
`draft`	0	1	Borrador (punto de partida)
`presented`	1	2	presentado para firma / mostrado
`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	sustituido
`verified`	9	512	verificación correcta (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 (ningún paso propio del ciclo de vida). Esta semántica de flags corresponde a la especificación «eventos como BitVector» (sin tipo union, pues son acumulativos).

El bloque de firma en el Ur-Doc

El Ur-Doc 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 circularidad de la identidad del sujeto (nombre base del documento/ID del contrato) — no del SHA de este documento —, para que pueda figurar en el Ur-Doc sin volver inestable el ancla de firma. Una mera referencia al nombre de archivo sería posible; la uuidV7 citada hace, no obstante, que el artefacto sea identificable por su nombre y es —porque se basa en la identidad y no en el contenido— estable. El estado, el proceso y los eventos residen exclusivamente en el artefacto de firma y/o en el GCPN.

Delimitación respecto de los artefactos vecinos

Artefacto	Rol	Mutabilidad
Ur-Doc (`{name}.md`)	Documento fuente con texto del contrato + facsímil	inmutable desde la firma
Ur-Doc-Sidecar (`{name}.md.gc.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`)	Procedimiento/expediente; `parents[]`/`children[]`	mutable
GCSIG (Commit) (`{abbrev}.gcsig.md`)	Commit de Git firmado con GPG	inmutable

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

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

Función Sidecar (Ur-Doc MD nativo). Si el Ur-Doc firmado se presenta de forma nativa como Markdown —sin escaneo, sin PDF, sin foto—, el *.gcsig.md puede servir a la vez como Sidecar: entonces porta (como un .gc.md) el ancla de contenido (SHA-256), el docUid y los metadatos y el ciclo de vida de firma en un único artefacto. No es imprescindible un .gc.md separado para ello.
Transición .gc.md → .gcsig.md (PDF firmado). Si se firma un PDF (o similar), el .gc.md que lo catalogaba puede pasar a un .gcsig.md. En ello no se pierde información: el contenido del Sidecar (ancla, docUid, clase, metadatos) se traslada al artefacto de firma. Pero el estado del Ur-Doc y su uso cambian: un justificante meramente catalogado pasa a ser un Ur-Doc firmado con su propio ciclo de vida de firma (BitVector de fases). No pueden coexistir Sidecars competidores entre sí: 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 .gc.md.

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

Reglas (normativas)

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

Referencias cruzadas

Parte I — Forma textual — Ur-Doc, Sidecar, Signatur-Doc, GCPN.
Parte II — FES y Facsimile — acoplamiento FES, capa Facsimile.
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