DS02 — Signatur-Doc như một kiểu dữ liệu (JSON-Schema)

Sự kiện kích hoạt S1, phần tiếp theo

E1 đã thông qua một nghị quyết (GVB) bằng Markdown. Bây giờ anh ta cần một artifact giúp nhận biết rõ: Tôi, E1, ký tài liệu này vào ngày X trong vai trò Y của mình. Artifact này phải đọc được bằng máy, được kiểm tra theo schema và an toàn phiên bản — một JSON-Artifact theo quy tắc 1 của GCBoK ("JSON-First") và quy tắc 4 ("Schema-First").

Kiểu dữ liệu `signature-1.0`

JSON-Schema định nghĩa chữ ký là một tài liệu độc lập trong repo — không phải tệp đính kèm, không phải văn bản thư. Cấu trúc cốt lõi (đơn giản hóa):

{
  "$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"
  }
}

Chi tiết từng trường bắt buộc

Nhóm trường	Bắt buộc	Mục đích
`uuidV7`	có	ID tất định từ dấu thời gian + doc-sha256 (gen-doc) — con dấu guid cho "accepted"/"signed"
`subject`	có	Người ký: tên, vai trò, thẩm quyền đại diện, pháp nhân
`target`	có	Tài liệu nguồn: tiêu đề, SHA-256, đường dẫn UNC — chữ ký gắn vào một phiên bản cụ thể
`procedure`	có	Thủ tục: textform/FES, quy phạm pháp luật, thông báo hình thức (§ 371a ZPO)
`evidence`	có	Tham chiếu Facsimile (SHA-256 + con dấu guid của đồ họa chữ ký), dấu thời gian
`signing_key_ref`	tùy chọn	Chỉ trong Phần III (vòng PII/GPG) — tham chiếu khóa, không trong Phần I/II

Quy tắc Schema-First: Trước mỗi lần ghi nhận, kiểm tra xem schema đã tồn tại hay chưa; nếu chưa có thì sẽ được tạo. Signatur-Doc tuân theo cùng một mẫu như diary-entry, v7g-sidecar và container GCPN.

Danh mục hóa V7GUID

Signatur-Doc nhận một V7GUID-Class-Taxonomy riêng trong sidecar (tương tự như SIGNATURE_GRAPHIC dành cho các asset đồ họa):

Class	Mục đích
`SIGNATURE_DOC`	Bản thân Signatur-Doc (JSON artifact)
`SIGNATURE_GRAPHIC`	Đồ họa Facsimile (PNG/SVG) — đã được đăng ký vào 260913
`SIGNATURE_EVENT`	Thao tác ký (Accept/Deny/Sign) — DS03

Mỗi class là một ứng viên promote cho OSS-Normative-Root (work/OSS/TOP/.gitcover/dictionaries/classes.json), tương tự như pilot 260821 (HR_REGISTER_DOC, RECEIPT_DOC v.v.).

Tại sao chữ ký là một tài liệu riêng

Ba quyết định thiết kế thúc đẩy saga:

Tách biệt giữa nội dung và tuyên bố ý chí — tài liệu nguồn giữ nguyên không đổi (Immutable-Doc); chữ ký là một artifact riêng biệt, tự gắn vào phiên bản cụ thể thông qua SHA-256. Một lỗi đánh máy trong tài liệu nguồn không làm vô hiệu hóa tầng chữ ký; một phiên bản mới tạo ra một chữ ký mới.
Đa chữ ký — nhiều người ký tạo ra nhiều Signatur-Doc cho cùng một tài liệu nguồn (ví dụ: GVB với hai dòng chữ ký). Việc xác minh kiểm tra tất cả các Signatur-Doc đối chiếu với cùng một SHA của tài liệu nguồn.
Khả năng kết nối FES — chữ ký FES (Phần II) không thay thế Signatur-Doc, mà bổ sung cho nó: Signatur-Doc vẫn là tầng repo, còn FES-Doc (Envelope-Report, PDF) được tham chiếu như một artifact khác.

Tham chiếu Facsimile (không nhúng)

Quan trọng đối với chất lượng saga: Signatur-Doc không nhúng đồ họa chữ ký một cách vật lý. Nó tham chiếu đến đồ họa đó — thông qua SHA-256 và con dấu guid (E1.Signature.transparent.FES.svg, sha256 8fcffe0b…, guid 01a09b48-4580-76f9-b789-024691b989c5). Điều này làm cho chuỗi trở nên nhẹ nhàng: đồ họa, tài liệu nguồn và Signatur-Doc có thể được kiểm tra độc lập; giá trị chứng cứ nằm ở việc xác minh, chứ không nằm ở việc nhúng.

Việc nhúng vật lý (Facsimile trong lớp PDF, theo kiểu DocuSign) thuộc Phần II — nơi chữ ký FES tạo ra một PDF-Doc riêng.

Tóm tắt

Signatur-Doc là một JSON artifact (schema signature-1.0) với các trường bắt buộc subject, target, procedure, evidence.
Nó gắn vào một phiên bản cụ thể của tài liệu nguồn thông qua SHA-256.
Đồ họa Facsimile được tham chiếu (SHA-256 + con dấu guid), không được nhúng — việc nhúng là nội dung của FES (Phần II).
Bài viết tiếp theo (DS03): thao tác ký dưới dạng Event.

Đã tạo: 260913 | Phần I, bài viết DS02 | Chuỗi: digital-signage