KB-B5BE

Council Review \u2014 \u011035 v5.1 DRAFT \u2014 Gemini Round 1

4 min read Revision 1

Council Review — Đ35 v5.1 DRAFT — Gemini Round 1

Tóm 1 câu

APPROVE WITH CHANGES: Dự thảo v5.1 giải quyết triệt để 4 Root Cause của phiên S177, đặc biệt là cơ chế Retrofit (§11) để xử lý dứt điểm 272 DOT cũ, tuy nhiên cần bổ sung định nghĩa cứng cho 2 hàm phụ trợ (fn_is_in_grace_period, fn_log_issue) để đảm bảo tính thực thi kỹ thuật.

Câu 1 — Xung đột HP

Dự thảo v5.1 không vi phạm Hiến pháp v4.5.1, trái lại còn tăng cường thực thi các nguyên tắc cốt lõi:

  • NT1 (Làm một lần dùng mãi): Khoản §11 Retrofit Clause là bước ngoặt lớn, chống lại tình trạng "legacy drift" (thực thể cũ vênh luật mới), đảm bảo hệ thống luôn đồng nhất.
  • NT7 (Dual-trigger): Khoản §5 bước 4 áp dụng triệt để NT7 bằng cách kết hợp dot-dot-register (động cơ chính) và Directus Flow [AUTO-ID] (lưới đỡ) để chặn đứng RC-4 (metadata NULL).
  • NT10 (Quản lý bằng PG): Việc thay thế CHECK hardcode bằng Reference Tables (§4.1) và sử dụng dot_config (§4.4) tuân thủ tuyệt đối NT10, giúp máy có thể validate và query dễ dàng.

Câu 2 — Xung đột luật khác

  • Đ22 Self-healing: Tương thích tốt. §8.1 và §8.3 yêu cầu bắt buộc ghi system_issues qua fn_log_issue(), tạo "cầu nối" dữ liệu để Đ22 có thể tự động nhận diện và sửa lỗi.
  • Đ31 Integrity: Hỗ trợ Đ31 bằng cách bổ sung H10-H13 (13 health checks), biến dot-dot-health thành scanner "mắt thần" cho chính hệ thống quản trị DOT.
  • Đ41 VPS Code Operation: Tuân thủ lộ trình triển khai (§9.2 và §11.3) dựa trên các bước tại Đ41 §13.5.
  • Đ32 Approval: Giữ nguyên tính nhất quán trong quy trình APR cho DOT cấp B (§3 và §5).
  • Lưu ý (§11.4): Quy định retrofit cho các luật tương lai là một bước tiến về "meta-law", nên được nhắc đến trong Đ38 (Luật Văn bản quy phạm) để có hiệu lực tổng thể cao hơn.

Câu 3 — Khả thi kỹ thuật

  • PG 16: Các cú pháp SQL (UNIQUE partial index, SECURITY DEFINER trigger) hoàn toàn tương thích với PG 16.
  • Hàm phụ trợ: Cần làm rõ: fn_is_in_grace_period()fn_log_issue() chưa thấy định nghĩa trong các file SQL hiện tại. Blocker nhẹ: Cần đính kèm source code 2 hàm này vào Block 3 (§9.2) để đảm bảo script không crash khi gọi.
  • UNIQUE partial index: Giải pháp dùng partial index WHERE file_path IS NOT NULL là cực kỳ thông minh, cho phép "sống chung với lũ" (45 cặp duplicate cũ) trong lúc chờ retrofit mà không làm hỏng logic DB.

Câu 4 — Rủi ro vận hành

  • Grace period (§4.1): 7 ngày cho 272 DOT cũ là "deadline" khá căng thẳng. Nếu DOT_METADATA_FILL không suy luận được 100%, áp lực manual backfill sẽ lớn.
  • Birth gate mode (§8.3): Mặc định warn lúc ban hành là quyết định an toàn (fail-open), tránh gây nghẽn CI/CD ngay lập tức.
  • Race condition (§11.3): Việc kịch hoạt đồng thời 6 DOT liên quan đến birth/metadata cần được thực hiện tuần tự (Backfill \u2192 Audit \u2192 Fill) để tránh xung đột dữ liệu trên dot_tools.

Câu 5 — Đề xuất cải thiện

  • Bổ sung định nghĩa: Thêm source code cho fn_is_in_grace_period() (check dựa trên dot_config.grace_period_daysdate_created) và fn_log_issue() (wrapper cho INSERT INTO system_issues).
  • Tách §11: Trong tương lai, nên đưa §11 Retrofit Clause thành một điều khoản chung của Hiến pháp hoặc Đ38 vì đây là nguyên tắc quản trị văn bản quy phạm tổng thể, không chỉ riêng cho DOT.
  • Wording §4.1: Cần quy định rõ cron_schedule cho manual DOT là chuỗi rỗng '' thay vì NULL để thống nhất với ràng buộc NOT NULL sau grace.

Điểm số 9/10

APPROVE WITH CHANGES.

  • Blocker: Phải bổ sung định nghĩa SQL cho 2 hàm phụ trợ trước khi merge PR ban hành.
  • Non-blocker: Cân nhắc di chuyển §11 sang luật cao hơn trong Round 2.