____12DS — Lược đồ gcpn-container-2.7: Tổng quan

Trình kích hoạt S6

Quy trình ký thực tế đầu tiên (GVB-Zeichnung) ban đầu tạo ra các tệp .json độc lập trong thư mục res/ — một cách làm việc khiến Git-Repo phình to (phát hiện AP: "việc này làm phình to Git-Repo một cách không cần thiết"). Phát hiện này dẫn đến việc sửa đổi: Tất cả tạo tác JSON trong MỘT Container-Doc (.gcpn.md, phần mở rộng lâu dài), và bản thân container trở thành lược đồ JSON quy phạm — gcpn-container-2.7.

Tổng quan về lược đồ

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

Phân định ranh giới: GCPN không phải Ur-Doc và không phải Sidecar; một .gcpn.md.gc.md riêng không còn. Tài liệu nguồn mang <artefakt>.<orig-ext>.gc.md riêng của nó; container tham chiếu nó qua referenced_doc (sha256) và mang GCPN-docUid riêng.

Tính duy nhất của tạo tác (phát hiện AP1)

Mỗi thực thể được mô tả đúng một lần:

Các quy tắc rút ra từ phát hiện

1. JSON luôn được nhúng (MD-Fence trong container) — không có tệp .json độc lập trong cây repo (tránh phình to).
2. Bổ sung thay vì tạo mới: Mỗi bước quy trình mới đặt một cờ, nhúng tạo tác mới, cập nhật summary — các tạo tác JSON đã được nhúng vẫn bất biến.
3. Bảo đảm truy vết sửa đổi nhờ Git: Lịch sử container nằm trong lịch sử Git của repo (mã băm commit = bằng chứng toàn vẹn).
4. Tài liệu có thể thay đổi, tạo tác JSON bất biến: MD của container có thể chỉnh sửa (phát triển theo quy trình); nội dung JSON là bất biến — thay đổi = tạo tác mới với SHA mới.
5. Chỉ commit qua E1 (NO-AUTO-COMMIT).

Tài liệu nguồn được lập danh mục qua lược đồ Sidecar

Một „lược đồ Ur-Doc" riêng là không cần thiết: Lược đồ v7g-sidecar-2.0 (.gc.md) là lược đồ JSON thực sự cho một tài liệu gốc/nguồn số — nó lập danh mục tài liệu nguồn qua sha256 (ID tài liệu, luôn nhận diện mọi lúc mọi nơi, kể cả khi di chuyển), locations (lịch sử UNC), v7g_taxonomy (lớp) và obsolescence/ lưu trữ. Container (referenced_doc) tham chiếu đến đó — hai tầng lược đồ, không dư thừa: Sidecar = lập danh mục tài liệu nguồn, Container = quy trình/quá trình.

Vì sao cần hai mã định danh — V7GUID là sổ đăng ký loại tài liệu, uuidV7 là Ref-Doc-UID

Điều này cũng làm rõ hơn, vì sao mỗi mã định danh lại cần thiết:

Sự phức tạp thoạt nhìn có vẻ như vậy (hai mã định danh thay vì một) lại chính là đòn bẩy cho tuân thủ dựa trên Git-Repo mà không bị khóa nhà cung cấp: Mọi thứ đều có thể được suy ra từ các repo (xác định một cách tất định) — không chỉ trạng thái tài liệu (chuỗi SHA-256, biểu thức cờ), mà còn cả lịch sử và thay đổi (lịch sử Git của container: bước nào được bổ sung khi nào; lịch sử Sidecar: hồ sơ phân loại kèm dấu thời gian). Không hệ thống độc quyền nào lưu giữ trạng thái — bản thân repo chính là trạng thái, và mọi kiểm tra viên có thể lặp lại việc suy ra bằng các công cụ mở.

Xác minh không dư thừa

Quy trình xác minh (DS04) vẫn giữ nguyên — nó làm việc với manifest trong container: sha256sum cho từng tạo tác đối chiếu với events.flags_set[].sha256 hoặc referenced_doc.sha256; chuỗi qua chain_valid; Facsimile-SHA đối chiếu với bảng trong SIGNATURE_BLOCK.md.

Biên bản kết quả nghiên cứu (AP)

---

Tạo: 260913 | Phần III, Bài viết ____12DS | Loạt bài: digital-signage