Incomex AI Portal
KB-62B0

Council Round 2 Prompt — Đ35 v5.1 DRAFT rev 2

11 min read Revision 1

PROMPT COUNCIL ROUND 2 — ĐIỀU 35 v5.1 DRAFT rev 2

Dành cho: Gemini 2.5 + GPT-5 (rà song song, độc lập) Ngày: 2026-04-14 S177 Fix 8 Ước tính: 20-30 phút mỗi agent Round 2 nguyên tắc: Round cuối nếu không có blocker mới. v5.1 cấp bách (272 DOT vênh, 49 DOT POST-S151 vẫn 94% NULL).

§1. ĐÃ TIẾP THU GÌ TỪ ROUND 1 (Desktop tổng hợp + sửa)

1.1 — 5 BLOCKER R1 — TẤT CẢ ĐÃ FIX TRỰC TIẾP TRÊN DRAFT

# Blocker R1 Ai nêu Fix trong rev 2
B1 fn_is_in_grace_period() chưa có bằng chứng tồn tại Cả 2 ★ Định nghĩa đầy đủ SQL trong §4.1B. Đọc dot_config.grace_period_days so với dot_config.law_v5_1_enacted_at. SECURITY DEFINER + SET search_path = public, pg_catalog. Owner workflow_admin. Fail-safe: NULL config → trả TRUE (giả định grace)
B2 fn_log_issue() chưa định nghĩa contract tối thiểu Gemini ★ Định nghĩa đầy đủ SQL trong §4.1B. 5 tham số (source, severity, category, summary, entity_code). Dedupe qua issue_signature = md5(source|category|entity|severity). UPSERT ON CONFLICT WHERE status='open' (chống bão duplicate). SECDEF + search_path. Yêu cầu phụ: system_issues.issue_signature UNIQUE WHERE status='open' (thêm trong BLOCK 1 nếu chưa có)
B3 _dot_origin lệch giữa §4.1 (không liệt kê) và §5/§8 (dùng) GPT ★ Thêm _dot_origin thành cột chính thức trong bảng §4.1 → 11 fields (không phải 10). NOT NULL DEFAULT 'unknown'. Mục đích truy vết RC-3 (3 lớp registry). Mọi reference §5.1 + §8.3 nhất quán với §4.1
B4 UNIQUE partial wording sai kỹ thuật (45 cặp dup non-null sẽ làm CREATE INDEX FAIL) GPT ★ Sửa wording §4.1 chính xác: partial chỉ cho phép nhiều NULL cùng tồn, KHÔNG cho phép duplicate non-null. Ghi rõ 45 cặp PHẢI dedupe TRƯỚC khi CREATE INDEX. §9.2 BLOCK 4 viết lại thành checklist cứng 12 bước (4.1 snapshot → 4.4 verify 0 dup → 4.6 backfill → 4.8 audit 0 drift → 4.9 CREATE INDEX → 4.10 NOT NULL)
B5 Dual-trigger không sống khi mode=block (flow PATCH-after-insert thất bại khi DB reject) GPT ★ Viết lại §5.2: 2 path mới — (a) trigger chính = pre-POST inference trong dot-dot-register (infer 11 fields TRƯỚC POST), (b) trigger phụ = cron dot-metadata-repair mỗi giờ (scan partial → infer + PATCH; fail → APR). Cả 2 sống cả khi mode=block. Flow [AUTO-ID] xuống vai trò "lưới đỡ phụ giai đoạn warn". Thêm DOT mới dot-metadata-repair (Tier B) + H13 check

1.2 — 5 NON-BLOCKER R1 — ĐÃ FIX

# Đề xuất Fix
1 Tiêu chí cứng warn → block §10 thêm 4 điều kiện AND (audit 0 drift 3 ngày liên tiếp + 0 dup non-null + dot-metadata-repair LIVE + H10-H13 PASS 3 ngày)
2 SECURITY DEFINER an toàn (SET search_path) Mọi function SECDEF v5.1 đặt SET search_path = public, pg_catalog. Owner workflow_admin
3 §11 wording cứng cho luật đã ban hành §11.4 viết hẳn câu cứng: "Mọi luật đang có hiệu lực mà tác động bảng có data cũ NHƯNG chưa có retrofit clause đều phải mở amend bổ sung retrofit trong kỳ sửa gần nhất. TRƯỚC KHI amend xong, KHÔNG được bật constraint/block mới làm legacy kẹt cứng." Tracker: retrofit-audit-tracker.md
4 Rule APR cho auto-backfill §11.2.1 mới: idempotent + có verify pair → auto-PATCH; mơ hồ/không idempotent → APR
5 Wording §5.1 NT11 (tránh hiểu "khai tay 11 cột") §5.1 ghi rõ: payload 11 fields = API boundary contract, ưu tiên infer tự động, không buộc khai tay

1.3 — KHÔNG SỬA + LÝ DO

Đề xuất Lý do giữ nguyên
Đổi tên fn_birth_gate → fn_dot_metadata_gate (Gemini + GPT lưu ý) Function đã deploy thật trên VPS cho dot_tools (133 collection có trigger từ dot-birth-trigger-setup). Đổi tên = migrate trigger 133 collection = rủi ro lớn cho 1 lợi ích thuần wording. Thay bằng: §8.3 chú thích rõ "Đ35-scope: dot_tools" để phân biệt với Đ0-G generic birth gate
Tách §11 thành meta-law riêng (cả 2 đề xuất) Cả 2 council đều nói "chưa nên tách lúc này". Đang chữa cấp cứu Đ35 → giữ §11 trong Đ35. Tách meta-law sau khi hệ ổn (ghi vào TD tương lai)
Grace 7 ngày (Gemini lo ngắn) Giữ 7 ngày default + thêm wording §9.3 "có thể gia hạn qua config mà không sửa luật" + §10 cứng "chưa đủ 4 điều kiện = giữ warn + gia hạn grace". Vận hành an toàn

1.4 — SỬA LỖI VIỆN DẪN PHÁT HIỆN THÊM (ngoài R1)

★ HP v4.5.1 thực tế chỉ có 11 NT (Desktop verify trực tiếp constitution.md). Draft rev 1 viện dẫn NT12 (paired_dot) + NT13 (PG First) ở §3, §8, §10 đều sai số điều. Rev 2 đã bỏ tham chiếu NT số sai — chuyển thành "quy tắc nội tại Đ35" (paired_dot rule) hoặc viện 11 NT đúng. Bài học: GPT R1 chỉ ra điểm này gián tiếp ("trong HP v4.5.1 hiện hành tôi không thấy NT13") — đáng cảm ơn.

§2. DỰ THẢO CẦN RÀ

File: knowledge/dev/laws/dieu35-dot-governance-law-v5-1-draft.md rev 2

Đọc bằng get_document_for_rewrite để có full content (search_knowledge chỉ trả tóm tắt).

§3. YÊU CẦU RÀ R2 — 5 CÂU HỎI SÂU HƠN

Trả lời tại knowledge/current-state/reports/council-review-dieu35-v5-1-<YOUR_NAME>-round2.md.

Câu 1 — VERIFY 5 BLOCKER R1 ĐÃ ĐÓNG ĐÚNG CÁCH

Với mỗi B1-B5, đánh giá:

  • Fix có đúng không? Có chỗ nào còn nửa vời?
  • SQL function (fn_is_in_grace_period, fn_log_issue, fn_birth_gate v5.1) — có compile được không? Có race condition nào trong UPSERT fn_log_issue?
  • §4.1 thêm _dot_origin có đụng schema migration nào (vd backfill 'unknown' cho 272 DOT cũ — cần ghi rõ ở BLOCK 2 không)?
  • BLOCK 4 checklist 12 bước có còn lỗ hổng nào không? (vd: bước 4.3 retire row dư — UPDATE file_path=NULL có làm mất audit trail không?)
  • Dual-trigger mới (dot-metadata-repair cron 1h) — bão APR khi engine vừa fix RC-2 + RC-4 chưa xong → cron quét → tạo APR liên tục cho cùng row → có dedupe đủ không?

Câu 2 — EDGE CASE PHÁT SINH SAU KHI SỬA

Sau khi v5.1 rev 2 deploy, có scenario nào CHƯA ĐƯỢC NGHĨ TỚI gây hỏng không?

  • Migration concurrent: nếu 2 agent chạy dot-dot-register đồng thời cho cùng file mới → race condition trên UNIQUE partial?
  • Grace period logic: law_v5_1_enacted_at UPDATE thủ công sau migration — nếu admin quên SET → fn_is_in_grace_period() trả TRUE mãi → grace mãi → block không bao giờ kích hoạt?
  • fn_log_issue UPSERT WHERE status='open': nếu issue đã 'resolved' rồi tái phát → tạo row mới hay update row cũ? Mong muốn?
  • dot-metadata-repair cron hỏng (last_executed > 2h) → H13 critical → tạo issue → nhưng ai fix dot-metadata-repair chính nó? Có self-paradox không?
  • BLOCK 4 bước 4.10 ALTER TABLE SET NOT NULL trên 6 cột đồng thời: nếu fail giữa chừng (cột 4 fail) → rollback toàn bộ hay partial? Cần BEGIN/COMMIT wrapper rõ ràng không?

Câu 3 — MIGRATION ORDER BLOCK 4 — STRESS TEST

Đánh giá thứ tự 12 bước BLOCK 4 §9.2:

  • Có scenario rollback nào (vd: bước 4.6 fail giữa chừng → 100/272 DOT đã PATCH, 172 chưa) → rollback an toàn không?
  • 4.5 (DOT_BIRTH_BACKFILL) phải chạy TRƯỚC 4.6 (DOT_METADATA_FILL) hay ngược lại? Lý do?
  • 4.9 (CREATE UNIQUE INDEX) có nên dùng CONCURRENTLY để không lock bảng không? (272 row thì ngắn nhưng nguyên tắc).
  • Bước 4.11 (enable cron) — nếu enable trước khi 4.12 (quan sát 24h) → cron có thể tạo issue làm nhiễu observation. Thứ tự 4.11→4.12 hay 4.12→4.11?
  • Có nên thêm bước 4.0 "snapshot toàn bộ dot_tools + system_issues" làm baseline rollback?

Câu 4 — AUDIT CHÉO LUẬT ĐÃ BAN HÀNH (theo §11.4 mới)

§11.4 yêu cầu mọi luật đã ban hành tác động bảng có data cũ + chưa có retrofit phải mở amend. Hãy chỉ rõ:

  • Đ36 Collection Protocol — có cần retrofit không? Bảng nào? Risk gì nếu không amend?
  • Đ37 Tổ chức Bộ máy — governance_registry data có sẵn trước Đ37 ban hành không? Cần retrofit không?
  • Đ38 Văn bản Quy phạm — normative_registry có data legacy không?
  • Đ39 Knowledge Graph — KG data trước S159 có cần retrofit theo schema v2.3 không?
  • Đ41 VPS Operation — vừa ban hành 2026-04-14, có data cũ trong vps_deploy_log (chưa tạo) hay layout /opt/incomex/ cũ không?

Ưu tiên xếp hạng (CRITICAL → LOW) các luật cần amend retrofit GẤP nhất.

Câu 5 — KẾT LUẬN BAN HÀNH

Cuối cùng:

  • v5.1 rev 2 đã đủ sạch để ban hành chưa?
  • Nếu APPROVE FINAL: liệt kê TODO post-merge (vd: tạo retrofit-audit-tracker.md, kích DOT_BIRTH_BACKFILL theo BLOCK 4, vá dot-dot-register payload 11 fields...)
  • Nếu APPROVE WITH MINOR CHANGES: chỉ rõ minor fix có thể làm INLINE trong PR ban hành (không cần Round 3)
  • Nếu REJECT / NEED ROUND 3: chỉ rõ blocker mới + lý do tại sao R2 chưa đủ

§4. ĐỊNH DẠNG BÁO CÁO YÊU CẦU

File: knowledge/current-state/reports/council-review-dieu35-v5-1-<gemini|gpt>-round2.md

Cấu trúc:

# Council Review — Đ35 v5.1 DRAFT rev 2 — <YOUR_NAME> Round 2

## Tóm 1 câu
[APPROVE FINAL / APPROVE WITH MINOR CHANGES / NEED ROUND 3]: lý do 1 câu

## Câu 1 — Verify 5 blocker R1 đã đóng đúng cách
[B1, B2, B3, B4, B5: đóng/nửa vời/sai cách + evidence]

## Câu 2 — Edge case phát sinh
[scenarios + risk level]

## Câu 3 — Migration order BLOCK 4 stress test
[đánh giá 12 bước + đề xuất nếu có]

## Câu 4 — Audit chéo luật đã ban hành
[Đ36/37/38/39/41: cần retrofit không, ưu tiên]

## Câu 5 — Kết luận ban hành
[APPROVE FINAL → TODO post-merge | APPROVE WITH MINOR → minor inline | NEED R3 → blocker mới]

## Điểm số 1-10 (so với rev 1)
[delta + giải thích]

§5. NGUYÊN TẮC RÀ R2

  • Không sáng tác nội dung mới — chỉ verify fix R1 + tìm edge case + audit chéo
  • Evidence cứng — trích §X điều khoản cụ thể của draft rev 2 + reference HP/luật khác
  • Áp 4-câu-hỏi-khung Huyên (memory): (1) Có luật chưa? (2) Đủ chưa? (3) Thực tế theo chưa? (4) Xung đột luật khác?
  • Nôm na khi kết luận — ví dụ đời thường để Huyên hiểu nhanh, không jargon
  • Không chắc = ghi rõ "không chắc"

§6. SAU R2

Desktop tổng hợp 2 báo cáo R2 → nếu cả 2 APPROVE FINAL → ban hành v5.1 + amend song song (OR soạn luật v1.1 + AP-22 anti-patterns + Skill Handoff v7) trong cùng PR. Nếu APPROVE WITH MINOR → fix inline + ban hành. Nếu NEED R3 → fix + R3 (hạn chế tối đa).

Cấp bách reminder: 272 DOT vênh, 49 DOT POST-S151 vẫn 94% NULL. v5.1 không ban hành = bệnh tiếp tục lan. R2 mong cả 2 APPROVE FINAL.