Incomex AI Portal
KB-116D

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

12 min read Revision 1
councilreviewfix24health-checkssotdieu22dieu35dieu36dieu37dieu43gpt2026-04-21

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

  • 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/dev/laws/law-22-self-healing.md
    • knowledge/dev/laws/dieu37-governance-organization-law.md
    • knowledge/dev/laws/dieu43-system-context-law.md
    • knowledge/dev/laws/dieu35-dot-governance-law.md
    • knowledge/dev/laws/dieu36-collection-protocol-law.md

1) Phán quyết tổng

Verdict: APPROVE WITH CHANGES

Điểm: 9.1/10

Đây là một hướng sửa đúng bệnh và đúng tầng. Tôi đồng ý với trục chính:

  • SSOT nội dung luật phải được nâng thành nguyên tắc ở Đ37;
  • hạ tầng health check phải gom về một nơi chung;
  • Đ22 là nơi hợp lý nhất để sở hữu hạ tầng vì đã sở hữu triết lý self-healing và vòng lặp phát hiện→xử lý→xác nhận;
  • Đ43/Đ35/Đ36 nên giữ nội dung check theo jurisdiction, không giữ hạ tầng riêng.

Bản dự thảo hiện đã đủ tốt để tiếp tục, nhưng nên sửa thêm một số điểm về schema, wording, và guard DDL để tránh tạo nợ kỹ thuật hoặc hiểu sai quyền sở hữu.

2) Câu 1 — Tuân thủ 13 NT

Đánh giá chung

Không thấy vi phạm nghiêm trọng. Dự thảo đi đúng hướng với các NT quan trọng nhất:

  • NT1 SSOT: PASS mạnh. Đây chính là mục tiêu trung tâm của Fix 24.
  • NT2 Tự động 100%: PASS có điều kiện. HC-TRIGGER + executor chung đẩy hệ về tự động hơn.
  • NT4 Sẵn sàng thay đổi: PASS tương đối. Dùng jurisdiction, metadata, seed rows là đúng hướng, nhưng chưa hoàn toàn “0 sửa code” ở mọi nơi vì vẫn còn đổi query source trong DOT scripts và migration logic cụ thể.
  • NT12 DOT cặp 2 chiều: PASS mạnh. Việc chuẩn hóa hạ tầng health check làm động cơ phụ auto-scale thật hơn.
  • NT13 PG First·Native·Driven: PASS mạnh. Dùng information_schema, bảng chung, config/rows, query path whitelist là hợp hiến.

Điểm cần chỉnh để PASS sạch hơn

  1. NT4: Câu “law_dot_enforcement UPDATE law_code → DOT tự chuyển jurisdiction, 0 sửa code” hiện hơi quá lạc quan. Với một số DOT đã hardcode nguồn query, migration thực tế vẫn có khả năng cần sửa SQL/script. Nên viết thành: “ưu tiên chuyển bằng metadata; nếu DOT hiện hành hardcode nguồn cũ thì phải migrate tối thiểu theo pattern chuẩn.”
  2. NT9: HC-TRIGGER auto-attach là DDL tự động. Nếu không thêm guard về quyền, idempotency, scope và xác nhận post-attach, có nguy cơ “không chắc mà vẫn sửa”.

3) Câu 2 — SSOT tầng luật: gom HC về Đ22 có đúng chuyên môn không?

Đúng. Đây là assignment hợp lý nhất.

Lý do

  • Đ22 đã là luật self-healing và đã có triết lý 2 động cơ.
  • Health check là hạ tầng tự phát hiện/tự sửa mang tính ngang hệ thống, không phải chuyên môn riêng của Đ43 hay Đ35.
  • Đ43 giỏi ở generic executor, nhưng chuyên môn bản chất của Đ43 là context pack/system map, không phải toàn bộ health-check infra.

Cách chia đúng sau sửa

  • Đ22: sở hữu hạ tầng chung (system_health_checks, generic executor, fix loop, audit, security guard)
  • Đ35/Đ36/Đ43: sở hữu nội dung check và seed rows theo jurisdiction
  • Đ37: sở hữu nguyên tắc phân quyền/chuyển giao ở tầng luật

Có gì nên ở luật khác không?

  • Không nên chuyển hạ tầng HC sang Đ31. Đ31 nên tiêu thụ hoặc tổng hợp kết quả integrity/systemic violations, không nên thành nơi sở hữu hạ tầng health-check runtime.
  • Đ43 chỉ nên giữ pattern executor như implementation precedent và chuyển giao vào Đ22.

4) Câu 3 — Schema system_health_checks: thiếu gì? jurisdiction nên FK hay text?

Đánh giá schema hiện tại

Schema draft là tốt, nhưng tôi đề nghị thêm vài cột/constraint để đủ cho vận hành dài hạn.

Nên bổ sung

  1. target_db TEXT NOT NULL DEFAULT 'directus'

    • Vì Hiến pháp hiện là 4 DB + 3 lớp.
    • Đ43 trước đó đã phải thêm target_db để xử lý multi-DB dispatch. Không nên lặp lại bài học quên DB scope.

  2. check_kind TEXT NOT NULL

    • Gợi ý enum/check: detect_only, detect_and_fix, verify_only
    • Hiện auto_fix_action có/không chưa đủ rõ loại check.

  3. cooldown_seconds INT NOT NULL DEFAULT 0

    • Tránh check/fix bị spam liên tục khi scheduler chạy dày hoặc khi lỗi chưa xử lý xong.

  4. expected_result JSONB DEFAULT '{}'::jsonb

    • Hữu ích cho check kiểu verify count / threshold / schema presence mà không hardcode trong executor.

  5. fix_executor_ref TEXT NULL thay vì chỉ auto_fix_action text mô tả

    • Nếu đã đi theo executor chung, phần fix cũng nên chuẩn hóa tham chiếu, không chỉ mô tả tự do.

  6. last_migrated_from TEXT NULL hoặc metadata tương đương trong giai đoạn chuyển giao

    • Giúp trace rows nào từ context_pack_health_checks, rows nào từ Đ35, rows nào mới.

Constraint nên thêm

  • unique (jurisdiction, order_index)
  • check jurisdiction <> ''
  • check code = lower(code) hoặc pattern code thống nhất nếu hệ có chuẩn naming
  • check auto_fix_action IS NULL OR executor_type IN ('builtin','sql','function') chưa đủ; tốt hơn là tách detect/fix refs rõ ràng

jurisdiction nên FK hay text?

Nên FK nếu registry luật đã ổn định.

Khuyến nghị tốt nhất:

  • jurisdiction FK vào normative_registry.code (không phải text tự do), vì Điều 38 đã thay law_registry bằng normative_registry.

Nếu vì rollout chưa sẵn sàng FK ngay, dùng lộ trình 2 bước:

  1. REV hiện tại: jurisdiction text + CHECK pattern ^dieu[0-9]+$ hoặc whitelist seed tạm
  2. REV sau / enact: nâng lên FK chính thức vào normative_registry.code

Tôi nghiêng về FK ngay nếu normative_registry đã chạy ổn. Đây là chỗ rất “NT10/NT1”.

5) Câu 4 — HC-TRIGGER auto-attach: rủi ro gì chưa nhận diện? Guard đã đủ chưa?

Chưa đủ. Dự thảo đã nhận diện đúng 1 phần, nhưng còn thiếu 5 rủi ro quan trọng:

R1. Quyền DDL / role escalation

Auto-attach trigger là DDL. Cần ghi rõ executor nào được phép làm việc này, chạy dưới role nào, và điều kiện nào mới dùng ADMIN fallback.

R2. Idempotency / duplicate trigger

Nếu attach lặp, có thể tạo trùng hoặc fail tùy DDL path. Cần:

  • kiểm tra trigger name trước,
  • naming convention chuẩn,
  • IF NOT EXISTS pattern hoặc block PL/pgSQL idempotent.

R3. Lock contention trên bảng đang bận ghi

CREATE TRIGGER có thể lấy lock. Nếu chạy lúc hệ đang busy, có thể gây delay. Nên có:

  • cửa sổ chạy,
  • timeout,
  • retry policy,
  • hoặc chỉ attach khi bảng không đang contention cao.

R4. False positive với bảng không nên gắn trigger dù có description

Hiện draft dựa vào governance_role='governed' + có cột description, là tốt nhưng chưa đủ. Nên loại trừ thêm:

  • views/materialized views nếu có,
  • foreign tables,
  • partition children,
  • các bảng special-case được mark enforcement_exempt=true trong config/registry.

R5. Hậu kiểm sau attach

Guard hiện mới nói “function đã tồn tại” + “quét lại xác nhận”. Nên viết rõ hậu kiểm gồm:

  • trigger hiện diện trong information_schema.triggers,
  • đúng function target,
  • insert test hoặc verify metadata pass,
  • log vào audit/repair log với correlation id.

Guard nên thêm

  1. fn_description_birth_guard() phải đúng signature và active version, không chỉ “tồn tại”.
  2. Chỉ auto-attach cho bảng có collection_registry.is_active=true và governance_role='governed'.
  3. Có cờ config global: hc_trigger_autofix_enabled.
  4. Có dry-run / propose mode trước khi attach thật.
  5. Ghi log vào bảng audit chuyên biệt, không chỉ text log.

Kết luận: HC-TRIGGER là ý hay và hợp NT5/NT12, nhưng cần thêm guard pháp lý + runtime rõ hơn trước khi enact.

6) Câu 5 — Đ37 §4.12 + §4.13: wording có kẽ hở không?

Có 2 kẽ hở cần bịt.

Kẽ hở 1 — “Luật gốc” dễ bị diễn giải cảm tính

Câu “Luật nào có chuyên môn BẢN CHẤT cho nội dung đó” đúng triết lý nhưng còn hơi cảm tính. Nên thêm tiêu chí xác định luật gốc:

  1. luật nào sở hữu khái niệm bản chất,
  2. luật nào sở hữu vòng đời/chính sách chính,
  3. luật nào sở hữu bảng PG hạ tầng chuẩn nhất,
  4. nếu hòa nhau → Hội đồng quyết định và ghi biên bản transfer.

Kẽ hở 2 — “Chuyển giao bằng UPDATE PG metadata, 0 sửa code” quá tuyệt đối

Nên đổi thành:

  • “Ưu tiên chuyển giao bằng metadata/config; nếu implementation hiện hành đã hardcode nguồn cũ thì phải migrate tối thiểu theo pattern chuẩn và ghi changelog.”

Quy trình chuyển giao nên thêm bước

Hiện draft nên bổ sung một quy trình 6 bước ngắn:

  1. phát hiện chồng chéo,
  2. xác định luật gốc,
  3. freeze nguồn cũ,
  4. migrate hạ tầng/rows,
  5. update references + verify parity,
  6. deprecate/drop nguồn cũ sau thời gian ổn định.

Điều này làm §4.12 usable hơn, tránh agent hiểu thành “muốn chuyển sao cũng được”.

7) Câu 6 — Tương thích ngược: Đ43 verify.sh và Đ35 dot-dot-health có risk gì?

Có, nhưng kiểm soát được.

Risk 1 — Query source đổi nhưng semantics không 1:1

Nếu context_pack_health_checks cũ có cột/logic riêng chưa map hết sang system_health_checks, script verify có thể chạy nhưng đọc thiếu meaning.

Risk 2 — Race window trong giai đoạn migration

Nếu DOT/script đã đổi query source nhưng rows chưa migrate đủ, verify báo thiếu giả.

Risk 3 — Order / active flags khác nhau

Nếu order_index, is_active, threshold config không migrate parity, hành vi executor có thể lệch.

Risk 4 — Whitelist path cho SQL executor

Dự thảo nói giữ guard SQL executor. Cần chắc query refs mới vẫn nằm đúng path whitelist; nếu không, migration xong nhưng executor từ chối chạy.

Khuyến nghị migration

  • chạy song song 2 nguồn trong cửa sổ ngắn (dual-read verify),
  • đối chiếu row count + code parity trước khi cut-over,
  • chỉ drop context_pack_health_checks sau 48h stable + parity pass như draft nói, điểm này là đúng.

8) Câu 7 — Thiếu sót: có luật nào khác cần sửa? Đ31 có nên gom HC vào không?

Luật có thể cần chạm nhẹ

  1. Đ38 (Normative / normative_registry)

    • Không cần sửa lớn ngay, nhưng nếu jurisdiction sẽ FK vào normative_registry, nên có ít nhất 1 ghi chú compatibility hoặc seed discipline để khỏi “nói FK nhưng registry không quản”.

  2. Đ31 (System Integrity)

    • Không nên gom HC vào Đ31.
    • Nhưng có thể cần tham chiếu nhẹ: Đ31 tiêu thụ kết quả/issue từ hạ tầng HC chung cho integrity reporting. Đ31 là consumer/aggregator, không phải owner của HC infra.

  3. Đ43 / Đ35 / Đ36

    • Ngoài chuyển giao mechanism, nên rà lại wording để không còn câu nào ngụ ý “sở hữu hạ tầng riêng”.

Bỏ sót nhỏ trong draft

  • Chưa nói rõ chiến lược migration với _dot_origin và provenance của rows cũ.
  • Chưa chốt FK/registry strategy cho jurisdiction.
  • Chưa nói rõ audit table nào ghi HC-TRIGGER auto-fix.

9) Khuyến nghị sửa cụ thể trước vòng sau

Bắt buộc nên sửa

  1. Thêm tiêu chí xác định luật gốc vào Đ37 §4.12.
  2. Nới câu “0 sửa code” thành “ưu tiên metadata/config; code migrate tối thiểu nếu implementation cũ hardcode”.
  3. Bổ sung guard cho HC-TRIGGER:
    • role/privilege,
    • idempotency,
    • lock/timeout,
    • exclude scope,
    • post-attach verification.
  4. Chốt jurisdiction theo hướng FK vào normative_registry.code hoặc ghi rõ lộ trình 2 bước.

Nên sửa

  1. Thêm target_db vào system_health_checks.
  2. Tách detect/fix semantics rõ hơn (check_kind, fix_executor_ref hoặc tương đương).
  3. Viết rõ quy trình migration dual-read/cut-over/parity check cho Đ43 và Đ35.

10) Kết luận ngắn

Bản dự thảo này rất mạnh ở tư duy kiến trúc. Nó xử lý đúng gốc rễ: health check bị phân mảnh vì thiếu SSOT ở tầng luật. Tôi đồng ý với trục sửa và không đề nghị reject.

Phán quyết cuối:

  • 9.1/10
  • APPROVE WITH CHANGES

Sau khi vá các điểm về schema/guard/wording nêu trên, bản này có thể lên khoảng 9.5–9.6/10 và đủ chắc để enact.