KB-404B

Council Prompt — Entity Enrichment Master Table — Vòng 1

5 min read Revision 1

councilround1entity-enrichmentmaster-tablearchitecturefix30

COUNCIL REVIEW — VÒNG 1: Dự thảo Bảng Master Entity Enrichment

Ngày: 2026-04-23 Tác giả dự thảo: Claude Desktop (S178 Fix 30) Yêu cầu: Ý kiến vòng 1 — đánh giá + phản biện + đề xuất sửa Ngưỡng: ≥ 7.5/10 mỗi reviewer. < 7.5 = sửa + vòng 2.

BỐI CẢNH — TẠI SAO CẦN REVIEW

Trong quá trình triển khai Description Enrichment (backfill mô tả chi tiết cho ~364 entity), phát hiện 3 vấn đề kiến trúc nghiêm trọng không thể giải quyết bằng sửa chữa nhỏ:

1. Pilot Gemini CLI thất bại: AI viết description trực tiếp lên entity → sai jurisdiction (P43 → Đ43), sai thuật ngữ (Sprint → Phiên), sai agent. Không có cơ chế duyệt, sai = ghi thẳng.

2. Text tự do = vỡ khi scale: Agent viết "Đ22" / "đ22" / "Điều 22" / "D22" — 4 cách ghi 1 thứ. Với 1,000 quy trình × 30 bước × 30 entity = 900,000 quan hệ → không thể quản lý text.

3. Không có toàn cảnh: Muốn biết "bao nhiêu entity chưa có jurisdiction" → phải JOIN 20 bảng. Không thể rà soát, không thể scale.

Giải pháp đề xuất: Thêm 1 bảng PG entity_enrichment làm master trung tâm. Mọi metadata enrichment viết ở đây, DOT sync xuống entity. FK chuẩn hóa, approved gate.

TÀI LIỆU CẦN ĐỌC

search_knowledge("dự thảo entity enrichment master table approved gate council")

Đọc file: knowledge/current-state/reports/du-thao-entity-enrichment-master-fix30.md

Tham chiếu luật hiện hành:

knowledge/dev/laws/constitution.md — HP v4.6.3 (14 NT)
knowledge/dev/laws/law-03-metadata.md — Đ3 rev 6
knowledge/dev/laws/law-04-birth-process.md — Đ4 rev 5
knowledge/dev/laws/law-22-self-healing.md — Đ22 rev 22
knowledge/dev/laws/dieu3-phu-luc-description-templates.md — Phụ lục Đ3 rev 3

CÂU HỎI CHO COUNCIL — 16 ĐIỂM ĐÁNH GIÁ

A. Kiến trúc bảng master (5 điểm)

Schema phù hợp? 14 cột đề xuất — thừa cột nào? Thiếu cột nào? Kiểu dữ liệu đúng?
1 bảng cho 500K+ rows — có rủi ro performance không? Cần partition không?
FK chuẩn hóa — jurisdiction FK normative_registry, species FK entity_species — đủ chưa? Thiếu FK nào?
PK = entity_code — đúng không? Hay cần composite PK (entity_code + source_table)?
Approved gate trigger — logic reset approved='no' khi sửa bất kỳ cột — đúng không? Có trường hợp nào approved KHÔNG NÊN reset?

B. Cơ chế sync (3 điểm)

Debounce 5 phút + 24h heartbeat — hợp lý cho single VPS? Rủi ro mất sync?
DOT sync cặp (NT12) — sync + verify đủ chưa? Cần thêm guard nào?
Seed khi birth — AFTER INSERT trigger seed master — timing có conflict với birth guard/provenance trigger hiện có?

C. Amend luật (4 điểm)

Đ3 §2.7 (MỚI) — đặt master table definition ở Đ3 có đúng SSOT không? Hay nên ở luật khác?
Đ4 thêm companion trigger 2 — birth process có quá nặng (3 trigger AFTER INSERT: provenance + master seed + birth_registry)?
Đ22 H11b mở rộng — scan master + scan entity có redundant? Cần 1 hay cả 2?
Đ36 đăng ký — entity_enrichment = governed, species governance_infra — đúng phân loại?

D. Tầm nhìn scale (2 điểm)

900,000 quan hệ tương lai (1,000 quy trình × 30 bước × 30 entity) — bảng master có chứa được? Cần thiết kế khác?
Thêm cột tương lai (project, workflow, step...) — ALTER TABLE đủ hay cần JSONB mở rộng?

E. Rủi ro + Vi phạm HP (2 điểm)

Vi phạm NT nào? Rà 14 NT — dự thảo có mâu thuẫn nguyên tắc nào không?
Rủi ro lớn nhất nếu triển khai? Rủi ro lớn nhất nếu KHÔNG triển khai (giữ nguyên hiện trạng)?

TIÊU CHÍ CHẤM ĐIỂM

Tiêu chí	Trọng số
Kiến trúc phù hợp HP 14 NT	30%
Schema + cơ chế đúng kỹ thuật PG	20%
Amend luật không xung đột	20%
Scale 500K+ rows + tương lai 900K quan hệ	15%
Thực thi được ngay (NT14)	15%

Ngưỡng: ≥ 7.5 APPROVE. 6.0–7.4 APPROVE WITH CHANGES. < 6.0 REJECT + viết lại.

FORMAT PHẢN HỒI MONG ĐỢI

ĐIỂM: X.X/10
VERDICT: APPROVE / APPROVE WITH CHANGES / REJECT

ĐÁNH GIÁ TỪNG MỤC:
A1: ... A2: ... A3: ... A4: ... A5: ...
B6: ... B7: ... B8: ...
C9: ... C10: ... C11: ... C12: ...
D13: ... D14: ...
E15: ... E16: ...

PATCHES ĐỀ XUẤT (nếu có):
P1: ...
P2: ...

NHẬN XÉT TỔNG THỂ:
...

Council Review Request — S178 Fix 30 | 2026-04-23