Incomex AI Portal
KB-5C92

Gemini Review Prompt Round 1 — Luật Loài + Collection

6 min read Revision 1
reviewgeminispeciescollectionround1

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

Copy toàn bộ nội dung bên dưới gửi cho Gemini.

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

VAI TRÒ

Bạn là chuyên gia governance và vận hành hệ thống (Governance & Operations Expert). Bạn đã review Hiến pháp Kiến trúc v3.0-v3.5 trước đây và đưa ra nhận xét: "The system is a well-built house with growing maintenance debt."

Lần này chúng tôi phát hiện lỗ hổng kiến trúc sâu hơn — ngôi nhà thiếu móng. Cần bạn phản biện mạnh từ góc vận hành thực tế.

BỐI CẢNH THẤT BẠI

2 tuần đếm nguyên tử không xong. Không phải kỹ thuật khó, mà:

  1. 134 collections trong PG, chỉ 19 đăng ký. 115 = mồ côi cả họ.
  2. Agent báo "KHỚP" nhưng chỉ đếm 7/19+ loại. Tự lừa mình.
  3. 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 collection đã đăng ký.
  4. Không kiểm soát từ khi sinh ra → đẻ bừa → chạy theo đếm → vẫn sai.

Người sáng lập: "Lẽ ra AI nên phản biện sớm hơn, thay vì thất bại rồi mới giải thích."

DỰ THẢO LUẬT MỚI (đọc toàn bộ)

Cốt lõi: 2 luật mới + 1 cơ chế

LUẬT LOÀI: Mỗi đối tượng PHẢI thuộc 1 loài (loại đối tượng). Không có loài = mồ côi. SSOT bảng loài liệt kê tất cả loài + mapping đến collection + lớp cấu tạo.

LUẬT COLLECTION: Mỗi collection PHẢI đăng ký + phân loại (managed/observed/infrastructure/junction/unclassified). Collection chưa phân loại = CẢNH BÁO ĐỎ. "Chuồng trước bò sau."

CƠ CHẾ SINH:

  • Cổng 1 (sinh loài): Hiếm, chặt, cần DOT riêng, chọn từ SSOT, xin ý kiến đặt tên
  • Cổng 2 (sinh cá thể): Thường xuyên, tự động theo luật đã định từ Cổng 1
  • Binding Loài→Collection 1 chiều → không nhầm chuồng
  • Đếm = audit check chéo (khai sinh vs thực tế PG). Khác = lỗi hệ thống.

Chi tiết

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ị.

5 nhóm collection: managed (đếm chi tiết), observed (COUNT*), infrastructure (không đếm), junction (COUNT*), unclassified (cảnh báo).

Collection chứa >1 loài: Phải note metadata danh sách loài. Collection tự đếm số loài.

Phương trình:

Tầng 1: Tổng PG = Σ(managed) + Σ(observed) + Σ(infra) + Σ(junction) + Σ(unclassified)
Tầng 2: Σ(managed) = Σ(6 lớp × loài) + Σ(mồ côi)
Tầng 3: Mỗi loài: khai sinh = thực tế → khác = lỗi hệ thống

Quan hệ luật hiện có:

  • Điều 0: thêm "phải có loài"
  • Điều 24: Loài = facet thứ 7? Hay meta-concept trước 6 facets?
  • Điều 26: Đếm = audit, không phải công cụ chính
  • meta_catalog: có thể thay bằng entity_species

Nợ kỹ thuật: 3 fields đếm mâu thuẫn (record_count, actual_count, active_count) + 17 triggers + verify_counts. Cần hợp nhất.

Quy mô dự kiến

  • Nguyên tử: ~20-50 loài × 100-5000 cá thể
  • Phân tử: ~50-200 loài × 10-1000 cá thể
  • Hợp chất+: hàng trăm-ngàn loài (chưa hình dung hết)
  • Ma trận đa chiều = bắt buộc chiến lược

YÊU CẦU GÓP Ý

A. VẬN HÀNH THỰC TẾ (★ góc nhìn chính của bạn)

Nghĩ như người phải TRIỂN KHAI dự thảo này trên production. Chỗ nào sẽ vỡ?

  1. Migration 115 collections chưa đăng ký: Ai phân loại? Bao lâu? Sai thì sao? Rollback?
  2. Cổng 1 trong thực tế: Agent A đang code feature mới, cần tạo loài mới, phải dừng xin phê duyệt. Workflow thực tế ra sao? Có blocking không?
  3. Cổng 2 khi DOT lỗi: Trigger BEFORE INSERT reject → cá thể không tạo được → feature bị block. Graceful degradation hay hard fail?
  4. 17 triggers + verify_counts đang chạy. Migration sang entity_species mà không break production — plan cụ thể?
  5. Collection mới tự phát hiện: PG trigger detect CREATE TABLE? Directus tạo collection khác CREATE TABLE thuần. Có chắc detect được?
  6. "Zombie" detection: Cá thể không hoạt động X ngày → cảnh báo. X = bao nhiêu? Mỗi loài khác nhau? Ai xử lý zombie?
  7. Đếm realtime khi scale: 50,000 records, 20 triggers fire mỗi INSERT. Latency? Cần batch count thay realtime?

B. GOVERNANCE

  1. Luật Loài + Luật Collection: gộp hay tách? Từ góc governance — ai enforce? Ai audit? Ai chịu trách nhiệm khi vi phạm?
  2. "Loài" vs Điều 24 (6 facets): Nếu loài = facet thứ 7 → phải sửa Điều 24 (đã ĐÓNG BĂNG). Nếu tách → 2 hệ thống nhãn song song. Rủi ro gì?
  3. Ai quyết tên loài mới? Người sáng lập? Orchestrator AI? Hay bất kỳ Agent nào? Naming convention enforcement?
  4. Audit trail: Khi phát hiện "khai sinh ≠ thực tế" → log ở đâu? Ai review? Auto-fix hay manual?

C. PHẢN BIỆN KIẾN TRÚC

  1. Dự thảo nói "Loài binding Collection 1 chiều." Nhưng nếu refactor collection (gộp/tách) → phải sửa binding → cascade impact?
  2. entity_species.record_count realtime: View? Trigger? Materialized view? Cụ thể mechanism nào? Mỗi cách có trade-off gì?
  3. 5 nhóm collection: "junction" có thật sự khác "managed"? entity_labels junction nhưng có 3640 records quan trọng. Ranh giới mờ?
  4. meta_catalog đã chạy stable 3+ tháng. Thay thế = rủi ro regression. Phương án "giữ meta_catalog + thêm entity_species bên cạnh" có tốt hơn "thay thế"?

D. VẾT XE ĐỔ

  1. Điều 26 viết xong, 2 tuần deploy không được. Dự thảo này phức tạp hơn Điều 26. Làm sao đảm bảo deploy thành công?
  2. Agent không hiểu luật → implement sai. Dự thảo ~3000 từ. Agent prompt window có hạn. Cần "Agent cheat sheet" tóm 10 dòng?
  3. Thứ tự triển khai: Nếu bước 3 (phân loại 134 collections) sai → bước 4-5 sai hết. Phương án rollback?

QUY TẮC

  • 🔴 CRITICAL / 🟡 IMPORTANT / 🟢 SUGGESTION
  • Mỗi ý: vấn đề + tại sao + giải pháp
  • "Cần cân nhắc thêm" = KHÔNG chấp nhận. Cân nhắc CÁI GÌ?
  • Ưu tiên phản biện. Cái đúng không cần nói. Cái sai mới cần.