PROMPT GPT ROUND 1 — Review Luật Loài + Luật Collection

Copy toàn bộ nội dung bên dưới gửi cho GPT. Sau khi GPT trả lời → lưu kết quả vào reports/.

YÊU CẦU GÓP Ý KIẾN TRÚC — Luật Loài + Luật Collection

VAI TRÒ CỦA BẠN

Bạn là kiến trúc sư phản biện (Architecture Critic) cho hệ thống quản lý tri thức Incomex. Bạn đã review Hiến pháp Kiến trúc v3.0-v3.5 và Luật Nhãn (Điều 24) trước đây. Lần này chúng tôi cần bạn phản biện mạnh — tìm lỗ hổng, rủi ro, mâu thuẫn — không chỉ đồng ý.

BỐI CẢNH THẤT BẠI (đọc kỹ trước khi review)

Hệ thống đã có Hiến pháp v3.5 (25 Điều) bao gồm Luật Đếm (Điều 26). Nhưng 2 tuần đếm nguyên tử không xong:

134 collections trong PostgreSQL, chỉ 19 được đăng ký — 115 collections = "mồ côi cả họ"
Agent báo "472 nguyên tử, KHỚP!" nhưng 472 chỉ là 7/19+ loại. PG có ~1513+ entities. Agent tự lừa mình.
entity_labels (3640 records), Fields (~5000) chưa được đếm — là nguyên tử quan trọng nhưng hệ thống không biết
Luật viết phổ quát, thực hiện vụ việc — Điều 26 nói "đếm TẤT CẢ" nhưng agent chỉ đếm 7 collection đã đăng ký

Nguyên nhân gốc (người sáng lập kết luận): "Định nghĩa đếm cái gì còn chưa cụ thể mà cứ đi đếm rồi loay hoay 2 tuần. Lẽ ra các bạn (AI) nên phản biện sớm hơn, thay vì thất bại rồi mới nói 'à nó thất bại vì...'"

→ Lỗ hổng kiến trúc: Thiếu 2 khái niệm nền tảng DƯỚI CẢ Điều 0.

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

Đọc theo thứ tự. Mỗi tài liệu tôi cung cấp nội dung bên dưới hoặc tóm tắt.

Tài liệu 1: Hiến pháp hiện có (tóm tắt các Điều liên quan)

Điều 0 — Thực thể Được Quản trị:

Thực thể = có code (PREFIX-NNN) + có trong registry + có metadata + thuộc 1 trong 6 lớp
meta_catalog = "bảng tuần hoàn" — hiện chỉ 19 managed + 2 log + 6 virtual = 27 records

Điều 0-B — 6 Lớp Cấu tạo:

nguyên tử → phân tử → hợp chất → vật liệu → sản phẩm → công trình
Mỗi thực thể PHẢI thuộc 1 lớp

Điều 24 — Luật Nhãn v1.3 (đã deploy):

6 chiều phân loại: domain, function, scope, lifecycle, quality, technology
6 facets × 6 lớp = ma trận 36 ô
entity_labels: 3640 records. 20 auto-label triggers. Rule 3 = BLOCKING.
ĐÓNG BĂNG sau 6 rounds review GPT+Gemini.

Điều 26 — Luật Đếm v2.1.1:

Record hoàn chỉnh = có code + có _dot_origin
Mồ côi L1 "lậu" (có code, không origin), L2 "di sản" (thiếu code), L3 "bò lạc" (OK nhưng biến mất UI)
Phương trình: tổng = đếm + mồ côi. Mồ côi > 0 = cảnh báo.
VẤN ĐỀ: Triển khai thất bại — chỉ đếm 7 collection atom, không đếm tổng PG.

Tài liệu 2: DỰ THẢO LUẬT LOÀI + LUẬT COLLECTION (v0.3)

Xin đọc toàn bộ dự thảo bên dưới:

I. VẤN ĐỀ

Thiếu 2 khái niệm nền tảng:

A. LOÀI (Entity Type): Mỗi đối tượng thuộc 1 "loài" — field, label, DOT tool, workflow, trigger... Nhưng không có SSOT liệt kê tất cả loài. Đối tượng mới sinh có thể không thuộc loài nào = mồ côi từ gốc.

B. COLLECTION (Thùng chứa): 134 collections, chỉ 19 đăng ký. 115 = mồ côi. Không có mapping Loài → Collection → Lớp.

Hệ quả: Collection mồ côi → records bên trong mồ côi → đếm sai → 2 tuần loay hoay.

II. TẦM NHÌN

Hệ thống tự động theo mục tiêu phổ quát (Agent đưa công thức → hệ thống tự lắp)
Mô hình vật lý: 108 nguyên tố → ngàn phân tử → vạn vật liệu
Quy mô: hàng ngàn loài × ngàn cá thể = hàng chục ngàn+ thực thể
Ma trận đa chiều = bắt buộc cho quản lý và biểu diễn

III. CƠ CHẾ KIỂM SOÁT SINH SẢN

"Chuẩn bị mua bò → phải chuẩn bị chuồng trước." Phân tách rõ: SINH LOÀI vs SINH CÁ THỂ.

CỔNG 1 — SINH LOÀI (hiếm, chặt):

Kiểm tra: loài đã có trong SSOT chưa? → Có thì dùng, không tạo mới
CHUẨN BỊ CHUỒNG: Collection chứa có chưa? → Chưa thì tạo collection TRƯỚC
Xin ý kiến đặt tên (tên loài theo tên collection)
Chọn lớp cấu tạo (atom/molecule/.../building)
Đăng ký vào SSOT bảng loài (DOT riêng: dot-species-register)
Kết quả: 1 record mới trong bảng loài + collection sẵn sàng

CỔNG 2 — SINH CÁ THỂ (thường xuyên, tự động):

Agent tạo record mới
TỰ ĐỘNG xác định loài từ collection (mapping đã có từ Cổng 1)
TỰ ĐỘNG gán code, _dot_origin, composition_level
TỰ ĐỘNG cập nhật đếm
KHÔNG NHẦM CHUỒNG vì loài → collection binding có sẵn

ĐẾM = AUDIT CHECK CHÉO:

Danh sách khai sinh (registry) vs thực tế PG (COUNT*)
Khác nhau → LỖI HỆ THỐNG (DOT lỗi, mất net, VPS sự cố...) → không phải lỗi dữ liệu
Kiểm soát đầu vào = công cụ chính. Đếm = check lại.
Ví dụ: Khai sinh 10 chiến sĩ, đếm thực = 9 → có 1 "ngã xuống ao" → tìm nguyên nhân hệ thống.

IV. LUẬT LOÀI

Mỗi đối tượng PHẢI thuộc 1 LOÀI. Không có loài = mồ côi.

Loài = loại đối tượng = phân loại gốc nhất
Nhãn ĐẦU TIÊN đóng vào trán mọi đối tượng khi sinh ra
Tên loài CỐ GẮNG THEO TÊN COLLECTION (dot_tools → dot_tool)
SSOT Bảng Loài (entity_species): code, name, composition_level, collection_home, prefix, record_count (realtime), status
Loài cũng là thực thể quản trị (có code, registry, lifecycle)

V. LUẬT COLLECTION

Mỗi collection PHẢI đăng ký + phân loại. "Chuồng trước bò sau."

Phân loại 5 nhóm:

managed — thực thể quản trị, đếm chi tiết
observed — vận hành (log, changelog), chỉ COUNT(*)
infrastructure — Directus internal, không đếm
junction — bảng quan hệ, COUNT(*)
unclassified — CẢNH BÁO ĐỎ

Collection chứa > 1 loài → PHẢI note metadata ghi rõ danh sách loài. Collection tự đếm số loài chứa.

Binding: Loài quy định Collection → 1 chiều → không nhầm chuồng.

Collection cũng là thực thể quản trị.

Tự phát hiện lỗi: collection mới chưa đăng ký → system_issue. Loài chưa có collection_home → constraint. Nhầm chuồng → trigger BEFORE INSERT.

VI. PHƯƠNG TRÌNH

Tầng 1 (toàn PG, luôn đúng):
  Tổng PG = Σ(managed) + Σ(observed) + Σ(infra) + Σ(junction) + Σ(unclassified)
  unclassified > 0 → CẢNH BÁO

Tầng 2 (managed chi tiết):
  Σ(managed) = Σ(6 lớp × loài) + Σ(mồ côi)

Tầng 3 (mỗi loài):
  Loài X: khai sinh [a] = thực tế [b] → khác → lỗi hệ thống

VII. NỢ KỸ THUẬT

TD-330: Hiện có 3 fields đếm mâu thuẫn trong meta_catalog (record_count, actual_count, active_count) + v_registry_counts + verify_counts() + 17 PG triggers. Cần hợp nhất sau khi Luật Loài deploy.

VIII. QUAN HỆ VỚI LUẬT HIỆN CÓ

Điều 0: thêm "mỗi thực thể PHẢI có loài"
Điều 0-B: enforce loài PHẢI có composition_level
Điều 24: Loài = facet thứ 7? Hay meta-concept trước 6 facets? CẦN REVIEW
Điều 26: Đếm = audit. Kiểm soát sinh = chính. Triết lý thay đổi.
meta_catalog: có thể thay/mở rộng bằng entity_species. CẦN REVIEW.

YÊU CẦU GÓP Ý CỤ THỂ

A. PHẢN BIỆN RỦI RO (★ ƯU TIÊN CAO NHẤT)

TẤN CÔNG dự thảo. Tìm lỗ hổng. Nghĩ chiều ngược: rủi ro nào khiến THẤT BẠI khi triển khai?

Phân loại collection sai ban đầu (managed↔observed) → hậu quả + cách phát hiện + cách sửa?
Hàng ngàn loài × ngàn cá thể — PG trigger realtime tắc? Khi nào chuyển materialized view?
Binding Loài→Collection 1 chiều — case nào vi phạm? Data cũ migration thế nào?
Cổng 1 quá chặt — bottleneck khi scale nhanh?
meta_catalog migration (19 records, 17 triggers, verify_counts) → downtime? Phức tạp?
Agent không hiểu dự thảo → implement sai? Cần đơn giản hóa gì?
"Luật viết xong nhưng deploy không được" (vết xe đổ Điều 26) → làm sao tránh?

B. KIẾN TRÚC

Luật Loài gộp Điều 0 hay tách Điều riêng? Tại sao?
"Loài" vs 6 facets Điều 24 — quan hệ gì? Facet thứ 7? Meta-concept? Tách biệt?
entity_species schema đủ chưa? Thiếu/thừa gì?
meta_catalog: giữ + mở rộng, hay thay bằng entity_species? Hay 2 bảng phân vai?
5 nhóm collection (managed/observed/infrastructure/junction/unclassified) đủ chưa?

C. CƠ CHẾ SINH

Cổng 1 (6 bước) đủ chặt chưa?
Cổng 2 rủi ro gì nếu hoàn toàn tự động?
Collection chứa nhiều loài — nên tránh hay chấp nhận?
Phát hiện zombie cá thể bằng cơ chế nào cụ thể?

D. QUY MÔ + TRIỂN KHAI

Ma trận phẳng giới hạn ở đâu? Khi nào chuyển đa chiều?
Thứ tự triển khai (Luật → SSOT → phân loại 134 collections → enforce → audit) hợp lý?

QUY TẮC GÓP Ý

Mỗi ý kiến đánh dấu:

🔴 CRITICAL — phải sửa, nếu không thất bại
🟡 IMPORTANT — nên sửa
🟢 SUGGESTION — hay nhưng không bắt buộc

Mỗi ý PHẢI có: Vấn đề cụ thể + Tại sao + Đề xuất giải pháp. "Cần cân nhắc thêm" = KHÔNG chấp nhận. Phải nói cân nhắc CÁI GÌ. Ưu tiên phản biện hơn đồng thuận. Cái đúng không cần nói. Cái sai mới cần.