GitCover Symbol GCBoKGitCover Body of Knowledge

____12DS — El esquema gcpn-container-1.0: Vista general

Desencadenante S6

El primer expediente de firma real (firma GVB) generó inicialmente archivos .json independientes en el directorio res/ — una forma de trabajar que hincha el Git-Repo (hallazgo del AP: "eso hincha el Git-Repo innecesariamente"). El hallazgo condujo a la corrección: Todos los artefactos JSON en UN doc contenedor (.gcpn.md, extensión permanente), y el propio contenedor se convierte en el JSON-Schema normativo — gcpn-container-1.0.

El esquema de un vistazo

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

Unicidad de los artefactos (hallazgo AP1)

Cada entidad se describe exactamente una vez:

Artefacto Cardinalidad Mecanismo de referencia
referenced_doc 1× Todas las demás referencias basadas en sha256 (sin repetición de título/ruta)
actor 1× (por cada parte implicada) Events/firma refieren mediante actor_ref → actor_id
retention 1× Por contenedor, no repetido por artefacto
attendees n× Referencias (actor_ref/tenant_ref), no personas
persons n× Puente PII pseudonimizado
signature 1× actor_ref + referencias Evidence
events 1× (objeto Flags) Bits + events_result
summary 1× sustituye las repeticiones de texto MD

Las reglas que se derivan del hallazgo

  1. JSON siempre incrustado (MD-Fence en el contenedor) — ningún archivo .json independiente en el árbol del repo (evitar el bloating).
  2. Completar en lugar de crear de nuevo: cada nuevo paso del proceso establece un flag, incrusta el nuevo artefacto, actualiza summary — los artefactos JSON ya incrustados permanecen inmutables.
  3. Seguridad revisional mediante Git: la historia del contenedor reside en la historia Git del repo (hash de commit = prueba de integridad).
  4. Doc mutable, artefactos JSON inmutables: el MD del contenedor es editable (crece con el expediente); 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 Ur-Doc" separado no es necesario: el esquema v7g-sidecar-1.0 (.v7g.md) es el verdadero JSON-Schema para un documento Ur-/fuente digital — cataloga el doc fuente mediante sha256 (ID del documento, lo identifica siempre y en todas partes, también al migrar), locations (historia UNC), v7g_taxonomy (clase) y obsolescence/Retention. El contenedor (referenced_doc) remite a él — dos niveles de esquema, sin redundancia: Sidecar = catalogización del doc fuente, Contenedor = expediente/proceso.

Para qué sirven los dos identificadores — V7GUID como registro Doc-Type, uuidV7 como UID de Ref-Doc

Con esto queda también más claro, para qué se necesita cada uno de los dos identificadores:

Identificador Rol de registro Propósito (determinismo)
V7GUID Registro Doc-Type Clasificar (¿qué tipo de artefacto?), encuadrar (en taxonomía/esfera), determinar workflows y metodología — la clase determina qué procedimientos se aplican
uuidV7 UID de Ref-Doc (seguridad revisional temporal) Identificador de instancia del acto de catalogación con marca de tiempo de 48 bits — cuándo se clasificó, ordenable cronológicamente

Esta complejidad aparente a primera vista (dos identificadores en lugar de uno) es justamente la palanca para una Compliance basada en Git-Repo sin Vendor Lock-In: todo se puede deducir de los repos (determinar de forma determinista) — no solo los estados de los docs (cadena SHA-256, expresión de flags), sino también la historia y los cambios (historia Git del contenedor: qué pasos se añadieron y cuándo; historia del sidecar: actas de clasificación con marcas de tiempo). Ningún sistema propietario almacena el estado — el propio repo es el estado, y cualquier auditor puede repetir la deducción con herramientas abiertas.

Verificación sin redundancia

La rutina de verificación (DS04) se mantiene — trabaja con el manifiesto del 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 ganancia de investigación (AP)

AP Hallazgo Característica del esquema
AP1 Bloat del repo por archivos individuales campo sidecar; incrustación JSON-Fence
AP2 Redundancia en participantes repetidos mecánica de referencia actor_ref
AP3 Retention/obsolescencia múltiples retention 1× por contenedor
AP4 Repeticiones de texto en el MD artefacto summary

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