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

Ngày: 2026-03-20 Vai trò: Kiến trúc sư phản biện Trọng tâm: TẤN CÔNG dự thảo, tìm lỗ hổng triển khai Tài liệu đã đọc qua Agent Data:

knowledge/dev/architecture/species-collection-law-draft.md

knowledge/dev/architecture/gpt-review-prompt-species-r1.md

knowledge/dev/architecture/information-atom-law.md (Điều 0)

knowledge/dev/architecture/composition-level-law.md (Điều 0-B)

knowledge/dev/architecture/label-law.md (Điều 24)

knowledge/dev/architecture/entity-lifecycle.md

knowledge/dev/ssot/operating-rules.md

Kết luận ngắn

Dự thảo đúng ở chẩn đoán bệnh, nhưng chưa đủ chặt để chữa bệnh. Lỗi lớn nhất là đang cố thêm 2 khái niệm mới vào hệ thống mà chưa khóa ranh giới giữa 4 thứ khác nhau: (1) loài, (2) collection, (3) lớp cấu tạo, (4) lớp quản lý/native-vs-managed. Nếu không tách dứt khoát, luật mới sẽ chỉ tạo thêm một tầng từ ngữ và một bảng mới, còn agent vẫn đếm sai như cũ nhưng theo tên đẹp hơn.

18 ý phản biện

1) 🔴 Loài đang chồng nghĩa với entity type của Điều 0

Vấn đề: Điều 0 đã có “Nguyên tố = Entity Type”, “meta_catalog = bảng tuần hoàn”. Dự thảo đưa “loài” như khái niệm mới nhưng mô tả gần như cùng nghĩa với entity type.

Tại sao: Nếu tồn tại đồng thời entity_type, species, meta_catalog, agent sẽ không biết cái nào là taxonomy gốc. Vi phạm tinh thần SSOT và “registry không co lại, chỉ tăng có kiểm soát”.

Giải pháp: Không được để “loài” là từ đồng nghĩa mơ hồ. Phải quyết 1 trong 2:

hoặc đổi tên luật thành luật Entity Type + Collection, dùng luôn ngôn ngữ Điều 0;
hoặc giữ từ “loài” nhưng formal hóa: species = governance taxonomy root, còn entity_type = tên kỹ thuật/legacy alias, và quy định rõ bảng nào là SSOT cuối cùng.

2) 🔴 Dự thảo mâu thuẫn nội bộ ở hướng mapping Loài↔Collection

Vấn đề: Mục 3.2 nói “tự động xác định loài từ collection”, nhưng mục 5.3 lại nói “Loài quy định Collection, KHÔNG ngược lại”.

Tại sao: Đây là mâu thuẫn vận hành. Nếu runtime suy loài từ collection thì collection đang là nguồn suy luận. Nếu loài quyết định collection thì runtime phải lấy loài làm input đầu tiên. Hai hướng này dẫn tới hai kiến trúc khác nhau.

Giải pháp: Chốt 3 lớp mapping rõ ràng:

Definition-time: species → allowed_collections
Runtime create: input bắt buộc = species, system chọn collection
Runtime audit/migration: record hiện hữu có thể infer species từ collection + discriminator rule

Tức là định nghĩa 1 chiều, audit có thể suy ngược có điều kiện. Nếu không viết rõ, agent sẽ implement sai.

3) 🔴 `entity_species` schema thiếu khóa quyết định cho multi-species collection

Vấn đề: Bảng đề xuất chỉ có collection_home một giá trị, nhưng chính dự thảo thừa nhận có collection chứa >1 loài.

Tại sao: Một field collection_home không đủ mô tả nhiều loài chung chuồng, cũng không đủ để phân biệt record nào thuộc loài nào trong cùng collection.

Giải pháp: Không dùng model 1 bảng loài + 1 field collection_home đơn giản. Phải thêm ít nhất:

species_collection_map(species_code, collection_name, is_home, discriminator_type, discriminator_expr, status)
species_resolution_rule hoặc JSON rule để chỉ ra cách phân biệt record trong collection đa loài.

Nếu không, câu “collection chứa nhiều loài” chỉ là phát biểu chính sách, không thể enforce.

4) 🔴 Chưa xử lý đúng “3 lớp quản lý” của Điều 0-B

Vấn đề: Dự thảo dùng “mỗi đối tượng phải thuộc 1 loài” như mệnh đề phổ quát, nhưng Điều 0-B đã tách 3 lớp quản lý: managed entity, native-managed resource, sub-atomic artifact.

Tại sao: Fields là native-managed, activity log là sub-atomic/native của Directus. Không thể áp cùng một chế độ registry, ID, lifecycle cho tất cả. Nếu ép phổ quát quá tay sẽ đẻ hệ thống song song — vi phạm Assembly First.

Giải pháp: Sửa câu luật thành:

“Mọi đối tượng nằm trong phạm vi governance count phải thuộc đúng 1 species-class.”
Species-class phải có governance_mode: managed | native_managed | observed | excluded

Không được dùng 1 câu tuyệt đối cho mọi object vật lý có mặt trong PG.

5) 🔴 5 nhóm collection chưa đủ để vận hành và sẽ gây phân loại sai hàng loạt

Vấn đề: Nhóm observed, infrastructure, junction đang quá thô; nhiều collection có thể vừa là junction vừa là governed, hoặc vừa vận hành vừa là bằng chứng audit.

Tại sao: entity_labels hiện là junction nhưng lại là hạ tầng phân loại cốt lõi; entity_dependencies trong Điều 0-B còn được xem như atom kiểu quan hệ. Nếu quăng toàn bộ vào “junction chỉ COUNT(*)”, hệ thống sẽ hạ thấp vai trò của các collection chiến lược.

Giải pháp: Tách classification thành ít nhất 2 trục thay vì 1 picklist:

storage_role: primary / junction / log / system
governance_role: governed / observed / excluded

Không nên cố nhét mọi ý nghĩa vào 5 nhãn phẳng.

6) 🔴 Cổng 1 chưa có bước “impact + anti-duplication” nên sẽ sinh loài trùng nghĩa

Vấn đề: Quy trình sinh loài hiện có check tồn tại, tạo chuồng, đặt tên, chọn lớp, đăng ký. Nhưng chưa bắt buộc scan trùng nghĩa với loài cũ.

Tại sao: Hệ thống đã có bài học từ dot-duplicate-engine, WCR/SCR review và luật chống trùng. Nếu không quét semantic duplicate, sẽ sớm có workflow_step, state_node, journey_step cùng bản chất nhưng khác tên.

Giải pháp: Thêm bước bắt buộc trước đăng ký:

semantic scan tên/description/prefix gần giống
scan relation overlap với loài hiện có
yêu cầu ghi rõ “không thể biểu diễn bằng loài cũ vì…”

7) 🔴 Cổng 2 “hoàn toàn tự động” sẽ thất bại với data không thuần 1-loài-1-collection

Vấn đề: Dự thảo mô tả Cổng 2 như máy tự gán toàn bộ: loài, code, origin, level, count.

Tại sao: Điều này chỉ đúng cho collection thuần, record thuần, flow tạo chuẩn. Với legacy data, import batch, table đa loài, junction record, hoặc native-managed resources, auto-resolution có thể sai mà vẫn “trông hợp lệ”. Sai âm thầm nguy hiểm hơn lỗi cứng.

Giải pháp: Chia Cổng 2 thành 3 mode:

strict_auto cho collection thuần 1 loài
rule_auto cho collection đa loài có discriminator rule
human_review_required cho legacy/import/mập mờ

8) 🔴 Triết lý “khác nhau = lỗi hệ thống, KHÔNG phải lỗi dữ liệu” là quá tuyệt đối

Vấn đề: Mục 3.3 và 6.4 quy kết lệch đếm là lỗi cổng/DOT/VPS, không phải lỗi dữ liệu.

Tại sao: Dữ liệu hoàn toàn có thể sai do migration lỗi, chỉnh tay, import sai định dạng, constraint thiếu, hoặc record legacy không đủ discriminator. Gọi tất cả là “lỗi hệ thống” làm mờ nguyên nhân gốc và làm đội sửa sai.

Giải pháp: Đổi taxonomy lỗi thành 3 nhóm:

system_fault (trigger/DOT/job/VPS)
data_fault (legacy/import/manual mutation)
model_fault (luật/mapping/discriminator sai)

Audit phải phân loại nguyên nhân, không được mặc định 1 nhãn.

9) 🔴 `record_count` realtime trên bảng loài dễ tạo thêm một hệ đếm cũ kiểu TD-330

Vấn đề: Bảng loài đề xuất có record_count sync realtime từ PG COUNT(*).

Tại sao: Hệ thống hiện đã đau vì nhiều trường đếm song song (record_count, actual_count, active_count, view, function, triggers). Nếu lại nhúng số đếm realtime vào một registry mới, sẽ tái tạo nợ kỹ thuật cũ với tên mới.

Giải pháp: Registry loài chỉ nên lưu metadata ổn định, không lưu count nóng trừ khi là snapshot có timestamp. Count sống nên đọc từ v_species_counts hoặc materialized view có SLA rõ ràng.

10) 🟡 Chưa có contract migration cho 115 collection mồ côi

Vấn đề: Dự thảo nói “mở rộng cover tất cả 134+”, nhưng không có chiến lược migration từng nhóm.

Tại sao: Không phải collection nào cũng nên được “quản trị” cùng mức. Nếu migrate ồ ạt, agent sẽ gán đại species cho đủ số, làm đẹp dashboard nhưng sai ontology.

Giải pháp: Migration phải đi theo 4 bucket:

bucket A: managed-ready
bucket B: observed-only
bucket C: excluded/system
bucket D: unresolved cần review

Chỉ bucket A mới được phép vào pipeline đếm chi tiết ngay.

11) 🟡 meta_catalog không nên bị thay thế vội

Vấn đề: Dự thảo mở khả năng “thay/mở rộng bằng entity_species”.

Tại sao: Điều 0 và 0-B đã đặt meta_catalog làm bảng tuần hoàn cấp nhận diện + composition_level. Thay thế trực diện sẽ đụng toàn bộ trigger, views, Directus pages, logic hiện có. Rủi ro downtime và semantic drift rất cao.

Giải pháp: Giai đoạn 1 phải để 2 bảng phân vai:

meta_catalog = registry của managed entity types theo Hiến pháp hiện hành
entity_species = governance ontology + mapping đến collection / native resources / exclusion

Sau khi chạy ổn và chứng minh không còn chồng nghĩa mới bàn hợp nhất.

12) 🟡 “Tên loài cố gắng theo tên collection” là heuristic nguy hiểm

Vấn đề: Dự thảo ưu tiên species name theo collection name.

Tại sao: Tên collection là quyết định storage, không phải luôn là quyết định ontology. Naming theo storage dễ khóa tư duy vào cấu trúc hiện tại và làm khó refactor sau này.

Giải pháp: Quy tắc naming nên là:

ưu tiên khái niệm nghiệp vụ/kiến trúc
collection name chỉ là alias hoặc default suggestion
lưu cả canonical_name, storage_alias, legacy_aliases

13) 🟡 Chưa định nghĩa rõ zombie detection nên mục 3.4 còn khẩu hiệu

Vấn đề: “active/deprecated/retired” có nói, nhưng không có tiêu chí xác định zombie cá thể.

Tại sao: Entity lifecycle đã có rule deprecated > 90 ngày, retired nhưng còn code reference = cảnh báo, USED_BY > 0 thì không retire. Dự thảo mới chưa nối vào bộ tiêu chí này.

Giải pháp: Zombie phải có định nghĩa có thể query, ví dụ:

status='active' nhưng không xuất hiện trong dependency/reference/activity trong N ngày
status='deprecated' quá SLA mà chưa migrate xong
retired nhưng vẫn bị reference

Vấn đề: Dự thảo đặt câu hỏi species có là facet thứ 7 không.

Tại sao: Facet của Điều 24 là phân loại đa chiều áp trên entity đã nhận diện. Species là định danh ontology gốc, đứng trước bước gán nhãn. Nếu biến species thành facet, agent có thể xem nó là một nhãn tùy chọn cùng hàng với domain/function, làm yếu luật nền.

Giải pháp: Chốt dứt khoát: species là meta-concept trước Điều 24, không phải facet thứ 7. Labels chỉ được gán sau khi species resolution thành công.

15) 🟡 Luật mới có nguy cơ vi phạm Assembly First nếu kéo agent vào tạo bảng mới trước khi tận dụng Directus/PG system tables

Vấn đề: Dự thảo nghiêng nhiều về tạo SSOT mới, registry mới, trigger mới.

Tại sao: Điều 0-B nhấn mạnh native-managed resource phải tận dụng Directus thay vì tạo hệ song song. Nếu không rà soát kỹ, “Luật Loài” có thể vô tình bọc lại những gì Directus đã quản lý tốt.

Giải pháp: Với từng species phải có field bắt buộc:

source_of_truth = directus | postgres | filesystem | derived
management_mode = native | overlay | full_registry

Chỉ loài nào thực sự cần full registry mới sinh collection riêng.

16) 🟡 Chưa có chuẩn thực thi để agent “không hiểu luật thì vẫn làm đúng”

Vấn đề: Dự thảo còn mang tính triết lý; nhiều đoạn đẹp nhưng chưa đủ machine-executable.

Tại sao: Điều 26 thất bại không phải vì thiếu triết lý mà vì agent triển khai theo cách hẹp. Nếu luật mới không biến thành contract cứng, lịch sử lặp lại.

Giải pháp: Mọi phần phải có 3 hiện thân đồng thời:

luật văn bản
schema/constraint/view/trigger tương ứng
checklist prompt cho agent với input/output cố định

Ví dụ Cổng 1 phải có form chuẩn: species_name, why_not_existing_species, collection_target, composition_level, management_mode, discriminator_rule, approval_required.

17) 🟢 Ma trận đa chiều chỉ nên làm sau khi ổn định ontology gốc

Vấn đề: Dự thảo nhắc scale “hàng ngàn loài × ngàn cá thể” và ma trận đa chiều như đích đến gần.

Tại sao: Nếu ontology species còn rung lắc, dựng ma trận sớm sẽ nhân sai số theo nhiều chiều và tạo dashboard đẹp nhưng nhiễu.

Giải pháp: Chỉ mở ma trận đa chiều khi đạt 3 điều kiện:

100% collections được bucket hóa
≥95% records trong phạm vi governance resolve được species không mơ hồ
count discrepancy giảm xuống ngưỡng cảnh báo đã định

18) 🟢 Thứ tự triển khai hiện tại đúng hướng nhưng thiếu bước “pilot 3 collection” trước khi enforce toàn hệ

Vấn đề: Roadmap đang đi từ luật → SSOT → phân loại 134 collections → enforce → audit.

Tại sao: Enforce trên toàn hệ ngay dễ gây vỡ hàng loạt vì mapping chưa chín.

Giải pháp: Chèn bước pilot bắt buộc:

đóng băng luật
dựng schema species + map
pilot trên 3 loại khó khác nhau: 1 managed thuần, 1 junction chiến lược, 1 native-managed
verify PG + Directus + Nuxt
mới rollout 134 collections

Trả lời dứt khoát 18 câu hỏi

Luật Loài nên tách Điều riêng, không gộp vào Điều 0; vì Điều 0 là luật nhận diện managed entity, còn species là ontology gốc. Luật Collection cũng nên tách riêng nhưng liên kết chặt với Điều 0-B.
Loài không phải facet thứ 7. Nó là meta-concept trước Điều 24.
Schema entity_species chưa đủ; thiếu mapping table, discriminator, governance mode, source_of_truth, aliasing, approval/audit fields.
meta_catalog nên giữ + mở rộng gián tiếp, chưa thay. 2 bảng phân vai.
5 nhóm collection chưa đủ nếu dùng như 1 trục duy nhất. Nên tách storage role và governance role.
Cổng 1 chưa đủ chặt; thiếu anti-duplication, impact analysis, source_of_truth, migration strategy.
Cổng 2 có rủi ro phân loại sai âm thầm, nhất là legacy/multi-species/import.
Binding 1 chiều chỉ đúng ở tầng định nghĩa; audit/migration có thể suy ngược có điều kiện.
Collection nhiều loài nên hạn chế mạnh, chỉ chấp nhận khi có discriminator rule máy đọc được; note text là không đủ.
Zombie phát hiện bằng query lifecycle + dependency + activity, không chỉ status.
PG handle được, nhưng không nên trigger realtime mọi count; ưu tiên view, index, materialized view khi query nóng vượt ngưỡng.
Ma trận đa chiều làm sau, khi ontology species ổn định và resolution rate đủ cao.
Thứ tự triển khai cơ bản hợp lý, nhưng thiếu pilot 3 collection và bucket migration.
TD-330 chỉ hợp nhất sau khi species mapping chạy ổn trên pilot + production subset, không làm đồng thời với khai sinh luật.
Phân loại collection sai ban đầu sẽ làm sai toàn bộ đếm và enforcement; cần bucket migration + audit views + override workflow.
Agent dễ implement sai nếu luật còn triết lý; cần contract hóa thành schema + prompt + DOT.
Muốn tránh “luật viết xong nhưng deploy không được” thì mọi mệnh đề phải có hiện thân DB/Directus/Nuxt tương ứng và test được.
Rủi ro lớn nhất tổng thể: tạo thêm SSOT mới nhưng không giải quyết ranh giới nghĩa giữa species, entity type, collection, level, governance mode.

Đề xuất chốt kiến trúc

Chốt 1 — Không dùng mô hình 1 bảng đơn

Phải dùng tối thiểu 3 thành phần:

entity_species
species_collection_map
species_resolution_audit

Chốt 2 — Phân biệt 5 khái niệm

species = ontology gốc
entity_type/meta_catalog = registry managed entity types hiện hành
collection = storage container
composition_level = lớp cấu tạo
management_mode = cách quản lý (managed/native/observed/excluded)

Chốt 3 — Mọi luật mới phải test qua pilot

Không pilot thì không enforce toàn hệ.

Phán quyết

Dự thảo chưa được freeze.

Có thể nói thẳng: bản này đúng hướng nhưng chưa đủ formal để triển khai an toàn. Nếu đem deploy ngay, hệ thống rất dễ rơi vào tình trạng:

có thêm bảng species,
dashboard mới đẹp hơn,
số đếm “hợp lý hơn”,
nhưng agent vẫn không phân biệt được đâu là ontology, đâu là storage, đâu là lifecycle, đâu là native-managed.

Khi đó thất bại Điều 26 sẽ lặp lại dưới tên mới.