GitCover Symbol GCBoKGitCover Body of Knowledge

Phần VI — Tài liệu được ký bằng Git: tạo tác chữ ký (GCSIG)

Kích hoạt S6: Một hợp đồng cần được ký theo cách Git-native. Nhưng ngay trước khi ký, phải có thể truy vết được tài liệu đã được hiển thị cho ai, khi nào, khi nào nó được phê duyệt và khi nào nó được ký. Vậy điều đó được ghi lại ở đâu, nếu bản thân Ur-Doc phải giữ bất biến?

Vấn đề: Các sự kiện cần một nơi

Các Phần I–III cho thấy một tài liệu (Ur-Doc), siêu dữ liệu của nó (Sidecar), các Signatur-Doc/sự kiện của nó và quy trình (GCPN) phối hợp với nhau như thế nào. Tuy nhiên, một điểm nhức nhối vẫn còn bỏ ngỏ: Các sự kiện của một tài liệu riêng lẻ — hiển thị (presented), phê duyệt (accepted), ký (signed) — cần một nơi riêng cho mỗi tài liệu, và ngay từ bản nháp.

Bản thân Ur-Doc không được mang nơi này. Nó — ngay khi đã được ký — là bất biến: Mọi thay đổi sau đó (kể cả chỉ một cờ trạng thái) đều làm thay đổi SHA-256 của nó và do đó khiến một chữ ký đã thực hiện trở nên vô hiệu. Ngay cả bản nháp cũng có thể là phiên bản cuối cùng; theo đó, không trạng thái, không lịch sử, không ghi chú quy trình nào thuộc vào Ur-Doc.

Giải pháp: một tạo tác chữ ký cho mỗi tài liệu (*.gcsig.md)

Với mỗi Ur-Doc .md được dự định ký, ngay từ bản nháp phải có một tạo tác chữ ký {name}.gcsig.md:

Tạo (công cụ 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>

Bitvector pha

Pha Bit Giá trị Ý nghĩa
draft 0 1 Bản nháp (điểm xuất phát)
presented 1 2 được trình để ký / đã hiển thị
accepted 2 4 được chấp nhận / đã phê duyệt
signed 3 8 đã ký
denied 4 16 bị từ chối
withdrawn 5 32 đã rút lại
revoked 6 64 đã thu hồi
expired 7 128 đã hết hạn
superseded 8 256 đã được thay thế
verified 9 512 xác minh thành công (bổ trợ trực giao)

Các bit tích lũy bằng OR trong phases.phases_result; current_phase được suy ra theo thứ tự ưu tiên (revoked > superseded > … > draft). verified là một bổ trợ trực giao (không phải một bước vòng đời riêng). Ngữ nghĩa cờ này tương ứng với yêu cầu “sự kiện dưới dạng BitVector” (không phải kiểu union, vì tích lũy).

Khối chữ ký trong Ur-Doc

Ur-Doc vẫn bất biến, nhưng sau khối chữ ký nhận được một phần giải thích ## Signatur (GCSIG), nêu tên tạo tác chữ ký tương ứng:

## 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)

uuidV7 (= docUid của GCSIG) được suy ra không vòng lặp từ danh tính chủ thể (tên cơ sở tài liệu/ID hợp đồng) — không từ SHA của tài liệu này —, để nó được phép đứng trong Ur-Doc mà không làm neo chữ ký trở nên không ổn định. Một tham chiếu chỉ bằng tên tệp cũng khả thi; nhưng uuidV7 được trích dẫn làm cho tạo tác có thể nhận diện theo tên và — vì dựa trên danh tính thay vì nội dung — ổn định. Trạng thái, quy trình và sự kiện nằm độc quyền trong tạo tác chữ ký và/hoặc GCPN.

Phân định với các tạo tác lân cận

Tạo tác Vai trò Tính khả biến
Ur-Doc ({name}.md) Tài liệu nguồn với văn bản hợp đồng + Facsimile bất biến từ khi ký
Ur-Doc-Sidecar ({name}.md.v7g.md) Siêu dữ liệu; SHA-256 = SSoT có thể thay đổi
Signatur-Artefakt ({name}.gcsig.md) Vòng đời chữ ký theo từng tài liệu, ngay từ bản nháp có thể thay đổi (vùng chứa pha)
GCPN ({name}.gcpn.md) Quy trình/hồ sơ; parents[]/children[] có thể thay đổi
GCSIG (Commit) ({abbrev}.gcsig.md) Git commit được ký GPG bất biến

GCSIG như Sidecar — và chuyển đổi .v7g.md → .gcsig.md

Tạo tác chữ ký không phải chỉ là một tài liệu bổ sung. Cần phân biệt hai trường hợp:

  1. Chức năng Sidecar (Ur-Doc MD gốc). Nếu Ur-Doc đã ký tồn tại nguyên bản dưới dạng Markdown — không phải bản quét, không phải PDF, không phải ảnh — thì *.gcsig.md đồng thời có thể đóng vai trò Sidecar: Khi đó nó mang (như một .v7g.md) neo nội dung (SHA-256), docUid và siêu dữ liệu và vòng đời chữ ký trong một tạo tác. Một .v7g.md riêng biệt không bắt buộc cho việc đó.

  2. Chuyển đổi .v7g.md → .gcsig.md (PDF đã ký). Nếu một PDF (hoặc tương tự) được ký, thì từ .v7g.md trước đó, vốn đang lập danh mục, có thể trở thành .gcsig.md. Trong quá trình đó, không có thông tin nào bị mất — nội dung Sidecar (neo, docUid, lớp, siêu dữ liệu) được chuyển vào tạo tác chữ ký. Nhưng trạng thái của Ur-Doc và việc sử dụng nó thay đổi: Từ một chứng từ chỉ được lập danh mục, nó trở thành một Ur-Doc đã ký với vòng đời chữ ký riêng (bitvector pha). Không được tồn tại các Sidecar cạnh tranh song song — nội dung được chuyển đổi, không bị nhân bản.

Tóm lại: GCSIG là một nơi duy nhất mà chữ ký của tài liệu này tồn tại — dù là tạo tác chữ ký thuần túy, ở vai trò Sidecar hay là kế thừa của một .v7g.md.

Tạo tác chữ ký được GCPN tham chiếu thông qua cạnh cây (GCSIG:{docUid}); ngược lại, nó nêu quy trình của mình qua gcpn_ref. Ngược lại, với các đối tượng Git (commit/tree/tag/PR), GCSIG vẫn là một tạo tác bất biến (gc-docsign gcsig <repo> --commit <sha>).

Quy tắc (quy phạm)

  1. Với mỗi Ur-Doc được dự định ký, ngay từ bản nháp phải tạo một *.gcsig.md (lược đồ gcsig-1.4); nếu không có tạo tác này, các sự kiện không thể được ghi lại.
  2. Ur-Doc vẫn bất biến: không trạng thái, không thông tin quy trình/lịch sử/ hash tự thân; chỉ có khối ## Signatur (GCSIG) với tham chiếu tên tệp.
  3. Trạng thái/sự kiện sống trong tạo tác chữ ký và/hoặc GCPN.
  4. Một *.gcsig.md từ một chữ ký gc (chữ ký commit) là một Ur-Doc bất biến; ngược lại, tạo tác theo từng tài liệu (document) là một vùng chứa pha có thể thay đổi.
  5. Với Ur-Doc MD gốc, *.gcsig.md đồng thời có thể là Sidecar (siêu dữ liệu + vòng đời trong một tạo tác). Với PDF đã ký, từ .v7g.md trước đó có thể trở thành .gcsig.md — không mất thông tin (chuyển nội dung), nhưng trạng thái/việc sử dụng Ur-Doc thay đổi; không có các Sidecar cạnh tranh.

Tham chiếu chéo

Đã tạo: 261008 | Nhà phát hành: ORG-1 (Trình giữ chỗ) | Chuỗi: digital-signage