____12DS — El esquema gcpn-container-2.7: descripción general

Disparador S6

El primer proceso de firma real (firma GVB) generó inicialmente archivos .json independientes en el directorio res/ — una forma de trabajar que infla el repositorio Git (hallazgo de AP: "esto infla innecesariamente el repositorio Git"). El hallazgo llevó a la corrección: Todos los artefactos JSON en UN solo documento contenedor (.gcpn.md, extensión permanente), y el propio contenedor se convierte en el esquema JSON normativo — gcpn-container-2.7.

El esquema en resumen

{
  "$schema": "https://gitcover.org/schemas/gcpn-container-2.7.schema.json",
  "container_id": "GCPN-SIG-YYMMDD-NNN",
  "docUid": "<deterministisch aus ts + doc-sha256>",
  "kind": "signature-process",
  "tenant": { … },
  "referenced_doc": { … },
  "actor": { … },
  "attendees": [ … ],
  "persons": { … },
  "retention": { … },
  "signature": { … },
  "events": { "flags_set": { … }, "events_result": 0, "enum_ref": "<uuidV7>" },
  "summary": { … },
  "prev_container": null,
  "next_container": null
}

Delimitación: El GCPN no es un documento original y no es un sidecar; ya no se necesita un .gcpn.md.gc.md separado. El documento fuente lleva su propio <artefakt>.<orig-ext>.gc.md; el contenedor lo referencia mediante referenced_doc (sha256) y lleva su propio GCPN-docUid.

Unicidad de artefactos (hallazgo AP1)

Cada entidad se describe exactamente una vez:

Las reglas que se derivan del hallazgo

1. JSON siempre embebido (bloque de código MD en el contenedor) — ningún archivo .json independiente en el árbol del repositorio (evitar el inflado).
2. Añadir en lugar de crear nuevos: Cada nuevo paso del proceso establece un flag, embebe el nuevo artefacto, actualiza summary — los artefactos JSON ya embebidos permanecen inmutables.
3. Seguridad de auditoría mediante Git: El historial del contenedor está en el historial de Git del repositorio (hash de commit = prueba de integridad).
4. Documento mutable, artefactos JSON inmutables: El MD del contenedor es editable (crece con el proceso); los contenidos JSON son inmutables — cambio = nuevo artefacto con nuevo SHA.
5. Commits solo mediante E1 (NO-AUTO-COMMIT).

El documento fuente está catalogado mediante el esquema sidecar

Un «esquema de documento original» separado no es necesario: El esquema v7g-sidecar-2.0 (.gc.md) es el verdadero esquema JSON para un documento original/fuente digital — cataloga el documento fuente mediante sha256 (ID de documento, identifica siempre y en todas partes, incluso al migrar), locations (historial UNC), v7g_taxonomy (clase) y obsolescence/ retención. El contenedor (referenced_doc) remite a él — dos niveles de esquema, sin redundancia: Sidecar = catalogación del documento fuente, Contenedor = trámite/proceso.

Para qué sirven las dos identificaciones — V7GUID como registro de tipo de documento, uuidV7 como Ref-Doc-UID

Con esto también queda más claro para qué se necesita cada una de las dos identificaciones:

Esta aparente complejidad a primera vista (dos identificaciones en lugar de una) es precisamente la palanca para cumplimiento basado en repositorios Git sin Vendor Lock-In: Todo se puede derivar de los repositorios (determinar de forma determinista) — no solo los estados del documento (cadena SHA-256, expresión de flags), sino también el historial y los cambios (historial Git del contenedor: qué pasos se añadieron y cuándo; historial del sidecar: actos de clasificación con marcas de tiempo). Ningún sistema propietario almacena el estado — el propio repositorio es el estado, y cualquier verificador puede repetir la derivación con herramientas abiertas.

Verificación sin redundancia

La rutina de verificación (DS04) permanece — trabaja con el manifiesto en el contenedor: sha256sum por artefacto contra events.flags_set[].sha256 o referenced_doc.sha256; cadena mediante chain_valid; SHA del facsímil contra la tabla en SIGNATURE_BLOCK.md.

Protocolo de hallazgos de investigación (AP)

---

Creado: 260913 | Parte III, artículo ____12DS | Serie: digital-signage