Council Review — SSOT Nội dung Luật + Hạ tầng Health Check (Fix 24) — GPT Vòng 2 Confirm (REV 2b)

Ngày: 2026-04-21
Agent: Incomex Hội đồng AI (GPT)
Tài liệu chính: knowledge/current-state/reports/du-thao-sua-luat-ssot-noi-dung-luat-hc-ha-tang-fix24.md
Căn cứ đã đọc:
- knowledge/dev/laws/constitution.md
- knowledge/current-state/reports/council-review-fix24-ssot-hc-round1-gpt-2026-04-21.md
Ghi chú: path review Gemini vòng 1 được nêu trong prompt hiện không đọc được từ Agent Data (not_found), nên xác nhận vòng 2 này bám theo REV 2b thực tế + feedback đã mô tả trong changelog.

1) Phán quyết tổng

Verdict: APPROVE FINAL

Điểm: 9.7/10

REV 2b đã đóng gần như toàn bộ các điểm lớn của vòng 1:

F1 FK cho jurisdiction là bước nâng chất lượng rất mạnh ở tầng NT1/NT10.
F3/F4 làm §4.12 của Đ37 vận hành được hơn nhiều, không còn quá cảm tính hay quá lý tưởng hóa "0 sửa code".
F5 đẩy HC-TRIGGER từ ý tưởng đúng thành cơ chế có guard tương đối trưởng thành.
F6 làm schema system_health_checks nhất quán hơn về semantics detect/fix.
F7 xử lý đúng bài toán migration thực tế: parity trước, cut-over sau.
F8 buộc transfer có dấu vết trong PG, không chỉ trong văn bản.
Và điểm mới Đ37 §4.14 là một bổ sung rất đúng thời điểm, xử thẳng bài toán AI đọc luật bị rơi liên kết.

Tôi không còn thấy blocker nào đủ lớn để giữ lại thêm một vòng revision bắt buộc.

2) Câu 1 — F1–F8 đã apply đúng ý chưa?

Kết luận chung

Có. Nhìn chung đã apply đúng ý.

F1 — `jurisdiction` FK

Đúng ý. Đây là điểm tôi từng muốn siết. Đưa jurisdiction về FK thay vì text tự do là nâng dự thảo lên rõ rệt.

Một lưu ý minor: cần thống nhất tuyệt đối naming giữa text ví dụ và FK thật. Trong REV 2b đang có ví dụ jurisdiction='LAW-43', LAW-36, LAW-35'. Cần chắc normative_registry.code thực sự dùng format đó. Nếu registry đang dùng format khác (ví dụ NRM-LAW-43-...) thì example trong luật phải đồng bộ 100%.

F2 — HC-REG thêm filter `pg_%`

Đúng ý. Hợp lý và đủ cho scope hiện tại.

F3 — 4 tiêu chí xác định luật gốc

Đúng ý. Đây là bản operational hóa tốt của nhận xét vòng 1.

F4 — Nới câu “0 sửa code”

Đúng ý. Câu mới thực tế hơn và không còn tuyệt đối hóa sai.

F5 — HC-TRIGGER 7 guards

Đúng ý, và đủ để lên mức enact. Tôi sẽ nói kỹ hơn ở Câu 5.

F6 — `check_kind`

Đúng ý. Nó làm rõ semantics detect-only / detect-and-fix / verify-only, rất đáng giá.

F7 — migration parity + dual-read

Đúng ý. Đây là chỗ rất quan trọng để tránh “chạy được nhưng lệch nghĩa”.

F8 — ghi nhận transfer vào `governance_audit_log`

Đúng ý. Đây là cách PG-native đúng hơn hẳn việc ghi nhận thuần văn bản.

3) Câu 2 — R1–R6 reject có thuyết phục không?

Kết luận chung

5/6 lý do reject là thuyết phục. 1/6 nên giữ mở cho phase sau nhưng không cần lật quyết định hiện tại.

R1 — `last_run_result` trên bảng chính

Reject hợp lý. Đồng ý. Bảng definition không nên trộn runtime result.

R2 — `target_db` column

Reject chấp nhận được trong scope hiện tại. Tôi từng đề xuất target_db, nhưng với lập luận hiện tại rằng executor chạy SQL/query trực tiếp và DB-target đã được quyết bởi path/query design, việc không thêm cột này là chấp nhận được ở Fix 24.

Tuy nhiên, đây là reject “hợp lý tạm thời”, không phải chân lý vĩnh viễn. Nếu mai sau system_health_checks mở rộng sang nhiều DB/FDW/executor phức tạp hơn, khả năng phải đưa target_db trở lại là có thật.

R3 — `fix_executor_ref`

Reject hợp lý. Với scope hiện tại, auto_fix_action + check_kind là đủ.

R4 — `cooldown_seconds`

Reject hợp lý. Scheduling là concern của scheduler/cron, không nên trộn vào definition table lúc này.

R5 — `expected_result JSONB`

Reject hợp lý. Nếu threshold_config đã bao được semantics này thì không nên đẻ field song song.

R6 — dry-run/propose mode

Reject hợp lý cho phase này. Tôi đồng ý không đưa vào Fix 24 để tránh phức tạp hóa. Nhưng vẫn nên coi đây là candidate tốt cho phase sau nếu HC-TRIGGER mở rộng quyền lực hơn.

4) Câu 3 — Schema rev 2: FK jurisdiction + `check_kind` + consistency constraint có vấn đề gì?

Không có vấn đề lớn. Đây là nâng cấp đúng.

Điểm mạnh

jurisdiction FK → sạch NT1/NT10 hơn hẳn.
check_kind giúp definition rõ loại check.
chk_kind_fix_consistency đúng hướng, ngăn detect-and-fix mà không có fix action.

Một điểm minor nên rà

Constraint hiện tại:

(check_kind = 'detect_and_fix' AND auto_fix_action IS NOT NULL)
OR (check_kind != 'detect_and_fix')

Về logic là ổn. Nhưng nếu muốn chặt hơn nữa, có thể cân nhắc:

verify_only nên có auto_fix_action IS NULL
detect_only nên có auto_fix_action IS NULL

Hiện constraint mới chỉ ép chiều “detect_and_fix thì phải có fix”, chưa ép chiều ngược “không phải detect_and_fix thì không được có fix”.

Đây là minor, không phải blocker. Nếu muốn tuyệt đối sạch nghĩa thì đổi thành:

(
  check_kind = 'detect_and_fix' AND auto_fix_action IS NOT NULL
)
OR (
  check_kind IN ('detect_only','verify_only') AND auto_fix_action IS NULL
)

Tôi nghiêng về nên chỉnh, nhưng không bắt buộc mở thêm một vòng revise vì điểm này nhỏ và dễ patch inline.

5) Câu 4 — Đ37 quy trình 6 bước đủ chưa?

Đủ để enact.

Trình tự hiện tại là đúng:

xác định luật gốc,
freeze nguồn cũ,
chuyển giao,
verify parity,
deprecate/drop,
ghi nhận transfer.

Một bổ sung minor đáng cân nhắc

Trong bước 2 hoặc bước 3 có thể nói rõ hơn:

freeze ở mức no-new-write vào nguồn cũ, không chỉ freeze diễn giải bằng lời.

Ví dụ wording tốt hơn:

Freeze nguồn cũ = không cho tạo check mới / không cho seed row mới vào hạ tầng cũ kể từ thời điểm chuyển giao.

Điểm này giúp agent/code hiểu freeze là trạng thái vận hành cụ thể, không phải khái niệm mơ hồ.

Nhưng tổng thể, 6 bước hiện tại đã đủ.

6) Câu 5 — HC-TRIGGER 7 guards đã đủ an toàn chưa?

Đủ an toàn cho enact trong scope hiện tại.

Bộ 7 guards hiện nay đã đóng đúng những lỗ đáng sợ nhất:

function tồn tại,
config gate,
idempotency,
lock timeout,
exclude scope,
post-attach verify,
audit trail.

Đây là mức guard đủ để DDL tự động không còn “liều”.

Một điểm minor nên nói rõ hơn

Ở guard số 5 “exclude scope”, nếu có thể nên viết rõ thêm một dòng trong dự thảo hoặc migration note rằng scope loại trừ gồm:

views,
foreign tables,
partition children,
object không thuộc schema public nếu có,
special-case tables được đánh dấu exempt.

Hiện prompt đã nói thế, nhưng draft rút gọn không liệt kê lại. Không phải blocker, nhưng liệt kê rõ sẽ tốt hơn cho người thi công.

Một điểm nữa

Guard số 7 đang nói admin_fallback_log + system_issues. Điều này chấp nhận được nếu:

system_issues là nơi nhận issue runtime,
admin_fallback_log là nơi giữ audit hành vi auto-DDL.

Tôi đồng ý với cách tách đôi này.

7) Câu 6 — Đ37 §4.14 tham chiếu liên luật 2 mức có đủ chặt không?

Có. Đây là một bổ sung rất tốt và đủ chặt để enact.

Đây là điểm tôi đánh giá cao nhất ở rev 2b ngoài schema. Nó đánh trúng vấn đề thực tế hiện nay: AI đọc luật theo text dễ bỏ sót liên luật, đặc biệt khi văn bản chưa metadata hóa đầy đủ.

Điểm mạnh

bắt buộc cả header-level lẫn inline-level,
nêu rõ “không đủ nếu chỉ 1 trong 2 mức”,
cấm duplicate nội dung luật khác,
chuẩn bị đường dẫn cho Đ38/Đ39 metadata hóa sau này.

Tôi khuyên bổ sung 1 format chuẩn cho block header

Đây là điểm duy nhất tôi muốn thêm. Hiện §4.14 nói phải có block ở đầu luật, nhưng chưa cho format tối thiểu. Nên chuẩn hóa ngay để agent không viết mỗi nơi một kiểu.

Format gợi ý

Ở đầu mỗi luật, thêm block cố định như sau:

## BLOCK THAM CHIẾU LIÊN LUẬT
- **SSOT chính:** [luật này sở hữu gì]
- **Phụ thuộc bắt buộc:** [Đxx, Đyy]
- **Mượn SSOT từ luật khác:** [nội dung A → Đxx §m.n]
- **Ưu tiên khi xung đột:** [HP > Đ37 > luật chuyên môn / hoặc quy tắc cụ thể]

Lợi ích:

AI đọc luật là thấy ngay dependency map,
dễ metadata hóa sau này,
giảm biến thể trình bày.

Wording nên chỉnh nhẹ

Câu:

"Khi xung đột → luật nào ƯU TIÊN (ví dụ: HP > Đ37 > luật chuyên môn)"

Nên cẩn thận hơn một chút, vì không phải mọi xung đột đều mặc định “Đ37 > luật chuyên môn”. Đ37 là luật tổ chức tầng quản trị, nhưng nội dung chuyên môn cụ thể có thể vẫn ưu tiên luật gốc chuyên môn sau khi đã xác định đúng jurisdiction.

Tôi khuyên sửa thành:

Khi có xung đột, PHẢI chỉ rõ quy tắc ưu tiên theo Hiến pháp và luật gốc đã xác định tại §4.12; không được ghi thứ tự ưu tiên mơ hồ.

Tức là giữ ví dụ minh họa, nhưng không biến ví dụ thành công thức tuyệt đối dễ gây hiểu sai.

8) Kết luận cuối

REV 2b đã đạt mức có thể chốt vòng Council.

Phán quyết

Điểm: 9.7/10
APPROVE FINAL

Hai chỉnh minor nếu muốn đẹp hơn nữa trước khi ban hành

Siết chk_kind_fix_consistency thành 2 chiều (không chỉ một chiều).
Chuẩn hóa format block header cho Đ37 §4.14 và tránh ví dụ thứ tự ưu tiên bị hiểu thành rule cứng.

Hai điểm này không đủ lớn để giữ lại thêm vòng revise. Có thể patch inline nếu muốn, hoặc để implementation guideline kèm theo enact.

Council Review — SSOT Nội dung Luật + Hạ tầng Health Check (Fix 24) — GPT Vòng 2 Confirm (REV 2b)

1) Phán quyết tổng

2) Câu 1 — F1–F8 đã apply đúng ý chưa?

Kết luận chung

F1 — jurisdiction FK

F2 — HC-REG thêm filter pg_%

F3 — 4 tiêu chí xác định luật gốc

F4 — Nới câu “0 sửa code”

F5 — HC-TRIGGER 7 guards

F6 — check_kind

F7 — migration parity + dual-read

F8 — ghi nhận transfer vào governance_audit_log

3) Câu 2 — R1–R6 reject có thuyết phục không?

Kết luận chung

R1 — last_run_result trên bảng chính

R2 — target_db column

R3 — fix_executor_ref

R4 — cooldown_seconds

R5 — expected_result JSONB

R6 — dry-run/propose mode

4) Câu 3 — Schema rev 2: FK jurisdiction + check_kind + consistency constraint có vấn đề gì?

Điểm mạnh

Một điểm minor nên rà

5) Câu 4 — Đ37 quy trình 6 bước đủ chưa?

Một bổ sung minor đáng cân nhắc

6) Câu 5 — HC-TRIGGER 7 guards đã đủ an toàn chưa?

Một điểm minor nên nói rõ hơn

Một điểm nữa

7) Câu 6 — Đ37 §4.14 tham chiếu liên luật 2 mức có đủ chặt không?

Điểm mạnh

Tôi khuyên bổ sung 1 format chuẩn cho block header

Format gợi ý

Wording nên chỉnh nhẹ

8) Kết luận cuối

Phán quyết

Hai chỉnh minor nếu muốn đẹp hơn nữa trước khi ban hành

F1 — `jurisdiction` FK

F2 — HC-REG thêm filter `pg_%`

F6 — `check_kind`

F8 — ghi nhận transfer vào `governance_audit_log`

R1 — `last_run_result` trên bảng chính

R2 — `target_db` column

R3 — `fix_executor_ref`

R4 — `cooldown_seconds`

R5 — `expected_result JSONB`

4) Câu 3 — Schema rev 2: FK jurisdiction + `check_kind` + consistency constraint có vấn đề gì?