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

Tóm 1 câu

APPROVE FINAL: Dự thảo v5.1 rev 2 đã đóng hoàn toàn 5 blocker kỹ thuật của Round 1, đồng thời thiết lập cơ chế Retrofit (§11) chuẩn mực để xử lý dứt điểm 272 DOT legacy mà không phá vỡ tính toàn vẹn của hệ thống.

Câu 1 — Verify 5 blocker R1 đã đóng đúng cách

B1: fn_is_in_grace_period() — [ĐÓNG ĐÚNG]

Evidence: §4.1B định nghĩa SQL rõ ràng. Sử dụng SECURITY DEFINER và SET search_path đúng chuẩn bảo mật (NT9).
Nhận xét: Cơ chế fail-open (NULL config → return TRUE) là quyết định sáng suốt để tránh kẹt hệ thống khi admin chưa kịp cấu hình. Logic TIMESTAMPTZ cast từ TEXT trong config là chuẩn PG16.
Catch: Cần đảm bảo bước ban hành có UPDATE dot_config SET value=NOW()::text WHERE key='law_v5_1_enacted_at'.

B2: fn_log_issue() — [ĐÓNG ĐÚNG]

Evidence: §4.1B định nghĩa contract 5 tham số. Sử dụng MD5 signature để dedupe issue đang mở (status='open').
Nhận xét: Việc tích hợp issue_signature vào system_issues là bước ngoặt giúp chấm dứt tình trạng "bão cảnh báo" (spam log).
Lưu ý: §9.2 BLOCK 1 đã bao gồm việc ALTER TABLE thêm cột này, đảm bảo tính khả thi.

B3: _dot_origin thành cột chính thức — [ĐÓNG ĐÚNG]

Evidence: §4.1 bảng 11 fields đã bao gồm _dot_origin. §9.2 BLOCK 2 có backfill 'legacy_pre_v5_1'.
Nhận xét: Đã nhất quán giữa schema (§4.1), quy trình đăng ký (§5.1) và gate (§8.3). Đây là chìa khoá để truy vết RC-3 (nguồn gốc DOT).

B4: UNIQUE partial wording — [ĐÓNG ĐÚNG]

Evidence: §4.1 sửa wording: "cho phép nhiều row NULL... KHÔNG cho phép duplicate non-null". §9.2 BLOCK 4 cung cấp checklist 12 bước xử lý dedupe trước khi tạo index.
Nhận xét: Đã phản ánh đúng bản chất kỹ thuật của PostgreSQL Partial Index. Việc yêu cầu dedupe trước khi tạo index là bắt buộc để tránh lỗi migration.

B5: Dual-trigger mới — [ĐÓNG ĐÚNG]

Evidence: §5.2 chia 2 đường độc lập: (a) Pre-POST inference (Engine chính) và (b) Cron metadata-repair (Lưới đỡ).
Nhận xét: Thiết kế này giải quyết được lỗ hổng "lưới đỡ đặt dưới đáy hố" của rev 1. Ngay cả khi DB ở chế độ block, engine dot-dot-register vẫn sống vì nó hoàn thiện metadata TRƯỚC khi đẩy vào DB.

Câu 2 — Edge case phát sinh (tối thiểu 5)

Scenario 1: Race condition khi 2 Agent đăng ký cùng 1 DOT mới — [MEDIUM]

Mô tả: Hai agent cùng chạy dot-dot-register cho cùng 1 file mới tạo.
Biện pháp: PG INSERT ... ON CONFLICT (code) DO NOTHING hoặc DO UPDATE sẽ xử lý tầng DB. Dual-trigger inference đảm bảo cả 2 đều có metadata chuẩn.

Scenario 2: Rollback BLOCK 4 thất bại giữa chừng — [HIGH]

Mô tả: Đang chạy Step 4.6 (PATCH 272 rows) thì crash ở row 150.
Biện pháp: Cần bọc Step 4.6 trong 1 transaction duy nhất (BEGIN/COMMIT). Vì bảng chỉ 272 rows, việc rollback 1 transaction là tức thì và an toàn.

Scenario 3: Grace period hết hạn trong khi cron repair đang chạy — [LOW]

Mô tả: Cron repair đang update metadata cho các row cũ thì kim đồng hồ nhảy qua mốc hết grace.
Biện pháp: Không ảnh hưởng. Gate chỉ chặn INSERT/UPDATE thiếu metadata. Cron repair là hành động bổ sung metadata, nên nó sẽ "giải cứu" row đó khỏi sự kiểm soát của gate.

Scenario 4: md5 signature collision — [LOW]

Mô tả: Hai issue khác nhau nhưng MD5 sinh ra trùng nhau.
Biện pháp: Xác suất cực thấp với MD5 cho chuỗi ngắn. Tuy nhiên, nếu xảy ra, issue thứ 2 sẽ update summary của issue 1 thay vì tạo mới. Không gây crash hệ thống.

Scenario 5: dot-metadata-repair tự gây lỗi cho chính mình — [MEDIUM]

Mô tả: DOT gác cổng bị hỏng metadata.
Biện pháp: H13 health check sẽ phát hiện nếu dot-metadata-repair không chạy > 2h và báo động đỏ (critical). Admin cần can thiệp tay bằng dot-dot-register --force.

Câu 3 — Stress test BLOCK 4 (12 bước)

a) Rollback giữa chừng

Dự thảo cần quy định rõ: Mọi Step từ 4.5 đến 4.10 phải chạy trong Transaction hoặc có script rollback tương ứng. Với 272 rows, khuyến nghị dùng Transaction PG cho từng Step.

b) Thứ tự 4.5 vs 4.6

Step 4.5 (BIRTH_BACKFILL): Tạo bản ghi khai sinh trong birth_registry.
Step 4.6 (METADATA_FILL): Điền metadata vào dot_tools.
Phân tích: Thứ tự hiện tại là đúng. Cần có "giấy khai sinh" (Step 4.5) làm căn cứ pháp lý trước khi "định danh" metadata (Step 4.6).

c) CONCURRENTLY

Với bảng dot_tools chỉ 272 rows, việc dùng CONCURRENTLY cho UNIQUE INDEX (Step 4.9) là không cần thiết và có thể gây phiền phức nếu chạy trong Transaction block. Nên dùng lệnh CREATE INDEX thường để tận dụng tính atomic của transaction migration.

d) 4.11 vs 4.12

Enable cron (4.11) trước khi quan sát (4.12) là logic đúng. Phải để máy chạy thì mới có dữ liệu để quan sát xem nó có đẻ ra issue mới không.

e) Bước 4.0 snapshot

Khuyến nghị bổ sung: Thêm bướcc 4.0: Snapshot toàn bộ dot_tools + system_issues vào bảng backup (ví dụ: dot_tools_pre_v5_1). Điều này cho phép phục hồi dữ liệu gốc nếu logic backfill ở Step 4.6 bị sai (vd: regex parse nhầm domain).

f) ALTER NOT NULL atomic

Nên gộp 6 câu lệnh ALTER COLUMN SET NOT NULL vào 1 câu lệnh ALTER TABLE duy nhất (như code mẫu §4.1) để PG thực hiện scan bảng 1 lần duy nhất, tối ưu hiệu năng.

Câu 4 — Audit chéo Đ36/37/38/39/41

Luật	Tác động bảng nào?	Có data cũ không?	Có §retrofit chưa?	Risk nếu KHÔNG amend	Ưu tiên
Đ36 Collection	`collection_registry`	Có (133+ col)	Chưa (chỉ có QT mồ côi)	Legacy collections thiếu domain/species chuẩn.	HIGH
Đ37 Tổ chức	`governance_units`	Có	Chưa	Cơ quan cũ không map đúng taxonomy mới.	MEDIUM
Đ38 Văn bản	`normative_documents`	Có (200+ docs)	Chưa (đang viết)	Scaffold cũ không query được theo chuẩn v3.0.	CRITICAL
Đ39 Knowledge Graph	`universal_edges`	Có (Phase 0/1)	Chưa	Cạnh cũ thiếu weight/confidence chuẩn v2.3.	MEDIUM
Đ41 VPS Operation	`vps_deploy_log`	Có	CÓ (§10)	Rủi ro thấp vì đã có sẵn cơ chế backfill sổ tay.	LOW

Xếp hạng ưu tiên amend:

Đ38 Văn bản: Vì đây là nguồn (Brain) cho mọi binding. Nếu scaffold lệch, AI sẽ đọc sai luật.
Đ36 Collection: Vì đây là khung (Warehouse) cho dữ liệu.
Đ39 Knowledge Graph: Để đảm bảo tính đồng nhất của Graph.
Đ37 Tổ chức: Quan trọng nhưng không gây crash logic vận hành ngay lập tức.
Đ41 VPS: Đã ổn định.

Câu 5 — Kết luận ban hành

(a) APPROVE FINAL — Ban hành ngay v5.1 rev 2.

TODO post-merge:

Thực hiện Step 4.0 (Snapshot) và kịch hoạt BLOCK 4 theo đúng checklist.
Cập nhật dot-dot-register để payload bao gồm 11 fields (thêm _dot_origin).
Tạo file knowledge/current-state/retrofit-audit-tracker.md để theo dõi tiến độ amend 5 luật trên.
Bật flow Directus [AUTO-ID] DOT Tools ở chế độ Active làm lưới đỡ phụ.
Thực hiện lệnh UPDATE dot_config SET value=NOW()::text WHERE key='law_v5_1_enacted_at'.

Điểm số 1-10 (so với rev 1)

Rev 1: 8.5/10
Rev 2: 9.8/10
Delta: +1.3
Giải thích delta: Dự thảo đã đạt độ chín về kỹ thuật, các hàm helper được định nghĩa SQL tường minh, cơ chế dual-trigger được thiết kế lại cực kỳ thông minh (pre-POST inference) giúp hệ thống sống sót cả khi bật chế độ block.