GPT Review Round 3 — Luật Loài + Collection v0.4

Ngày: 2026-03-20 Vai trò: Kiến trúc sư phản biện Mục tiêu: góp ý lần cuối trước khi đóng băng, tập trung pilot-readiness Tài liệu đã đọc qua Agent Data:

knowledge/dev/architecture/species-collection-law-draft.md (v0.4)

knowledge/dev/architecture/information-atom-law.md

knowledge/dev/architecture/composition-level-law.md

knowledge/dev/architecture/label-law.md

knowledge/dev/architecture/entity-lifecycle.md

knowledge/dev/ssot/operating-rules.md

các report review Round 1 + Round 2

Kết luận ngắn

v0.4 đã đủ để triển khai pilot.

Không nên kéo dài thêm vòng review lớn nữa. Tuy nhiên trước khi pilot, tôi vẫn thấy 3 khóa chặn nhỏ nhưng quan trọng cần ghi rõ hơn; nếu không, pilot vẫn chạy được nhưng dễ sinh hiểu sai hoặc sinh backlog audit:

species_collection_map chưa đủ formal cho case discriminator phức tạp.
Ranh giới 3 mode Cổng 2 vẫn còn hơi cảm tính, agent dễ chọn sai mode.
Câu "overlay ontology, không tạo registry song song thay native source" đúng tinh thần nhưng chưa đủ testable cho agent.

1) Đủ để pilot chưa?

🟢 Đủ để pilot

Vấn đề: Câu hỏi chính là v0.4 đã đủ chặt để triển khai pilot chưa.

Lý do: Những điểm từng nguy hiểm ở v0.3 đã được khóa lại khá tốt:

species đứng trước Điều 24
soft enforcement qua queue riêng
bỏ record_count khỏi entity_species
giữ meta_catalog song song
có 2 trục + source_kind
có pilot 3 loại và tiêu chí pilot
có execution gate cho ma trận đa chiều
có SLA + owner + 3 tầng xử lý audit

Bộ này đủ để kiểm tra kiến trúc trên phạm vi nhỏ mà chưa làm vỡ production semantics.

Giải pháp: Chốt luôn: đóng băng v0.4 để pilot, nhưng thêm 3 patch textual nhỏ dưới đây trước khi code.

2) Các điểm còn thiếu cụ thể trước khi pilot

🔴 `species_collection_map` chưa cover hết discriminator phức tạp

Vấn đề: Schema hiện chỉ có discriminator_field + discriminator_value.

Lý do: Chỉ cover được case rất đơn giản kiểu type = 'x'. Không cover được:

multi-field discriminator
range / pattern
null-vs-not-null
derived rule (prefix, relation, json path, exists)

Nếu pilot sau này đụng case phức tạp, agent sẽ lách bằng quy ước miệng.

Giải pháp: Thêm tối thiểu 2 field:

discriminator_operator = eq | in | regex | prefix | exists | is_null | json_path
discriminator_config = jsonb nullable

Với case đơn giản, vẫn dùng field + value. Với case phức tạp, dùng config. Không cần làm engine lớn ngay, chỉ cần chừa schema đúng.

🔴 Ranh giới 3 mode Cổng 2 chưa đủ testable

Vấn đề: strict_auto / rule_auto / human_review đúng ý tưởng nhưng agent vẫn có thể chọn mode theo cảm tính.

Lý do: Các mô tả hiện tại còn bằng lời. Khi implement, mỗi người sẽ hiểu “mơ hồ” khác nhau.

Giải pháp: Chốt tiêu chí máy đọc được:

strict_auto: collection map có đúng 1 species active, không có discriminator, không legacy/import flag
rule_auto: collection map có >1 species hoặc có discriminator rule
human_review: collection có migration_state != stable hoặc source_kind = native cần review, hoặc insert đến từ import/legacy channel

Tức là mode không do agent đoán, mà do metadata quyết định.

🟡 `source_kind` hiện đủ dùng cho pilot, nhưng chưa chắc đủ cho toàn hệ

Vấn đề: registry / native / derived / policy đủ cho v0.4 pilot.

Lý do: Với pilot hiện tại tôi chưa thấy collection nào “lọt” nghiêm trọng. Nhưng sau này có thể thiếu 1 loại cho queue/runtime/event.

Giải pháp: Không cần sửa trước pilot. Chỉ thêm note TD:

nếu phát sinh collection kiểu operational queue/event stream/work buffer, xem xét thêm runtime

Hiện tại: đủ cho pilot.

🟡 Performance circuit breaker 500ms là tạm ổn, nhưng câu luật còn hơi thô

Vấn đề: “Query > 500ms → chuyển materialized view” hơi cứng.

Lý do: Một lần query >500ms không đủ kết luận. Có thể do cold cache, network, hay query xấu tạm thời.

Giải pháp: Sửa câu cho chắc hơn:

p95 query time > 500ms trong 24h hoặc
3 lần đo liên tiếp trên query chuẩn đều > 500ms

Với pilot ngày mai thì 500ms là ngưỡng hợp lý, chỉ cần đổi từ “1 query” sang “ngưỡng quan sát có lặp lại”.

🔴 Câu “overlay ontology, không tạo registry song song thay native source” đúng ý nhưng chưa đủ để agent implement đúng

Vấn đề: Agent có thể vẫn hiểu sai giữa “overlay” và “replicate”.

Lý do: Câu hiện tại là nguyên tắc tốt, nhưng chưa có test oracle rõ ràng. Agent dễ làm một bảng mirror rồi bảo đó là “overlay”.

Giải pháp: Thêm 1 đoạn rule testable:

Overlay ontology được phép lưu classification, mapping, audit state
Overlay ontology không được lưu full-copy business fields của native source
Overlay ontology không được trở thành nơi update chính cho native-managed resource
Nếu xoá overlay mà native source vẫn chạy đúng chức năng gốc → đúng tinh thần overlay

Đây là câu cực quan trọng, nên ghi thẳng vào luật.

3) Đóng vai agent đọc cheat sheet 10 dòng — có đủ để implement đúng không?

🟡 Đủ để hiểu hướng, chưa đủ để tự implement đúng 100%

Vấn đề: Cheat sheet 10 dòng rất tốt cho định hướng, nhưng chưa đủ làm implementation spec độc lập.

Lý do: Agent đọc xong sẽ hiểu “phải làm gì”, nhưng vẫn còn mơ hồ ở 3 điểm:

Khi nào chọn strict_auto vs rule_auto vs human_review?
Audit issue tối thiểu phải ghi những field nào?
“Không tự đoán kín” nghĩa là tạo audit queue hay system_issue hay cả hai?

Giải pháp: Không cần sửa cheat sheet dài hơn. Chỉ cần thêm 3 dòng phụ trong Agent cheat sheet implementation annex hoặc trong prompt mẫu:

mode lấy từ metadata collection, không tự chọn
case không resolve → tạo entity_audit_queue
system_issue chỉ dùng cho lỗi hạ tầng; ambiguity species đi vào audit queue

🟢 Kết luận về cheat sheet

Cheat sheet hiện tại đủ cho agent hiểu luật, nhưng không đủ làm spec triển khai một mình. Điều này là bình thường. Vai trò của cheat sheet là nén luật, không thay schema contract.

4) Còn rủi ro nào chưa address trong v0.4?

🔴 Thiếu `resolution_confidence` hoặc tương đương trong audit flow

Vấn đề: species_guess có nhưng không có độ tin cậy.

Lý do: Agent-propose và auto-resolve cần phân biệt “chắc 99%” với “đoán 55%”. Nếu không, hàng review sẽ khó ưu tiên.

Giải pháp: Thêm optional field:

resolution_confidence numeric hoặc enum high/medium/low

🟡 Thiếu `migration_state` cho collection trong giai đoạn rollout

Vấn đề: Giai đoạn 1-2-3 migration đã có, nhưng chưa thấy field nào đánh dấu collection đang ở trạng thái nào.

Lý do: Cổng 2 mode và enforce timing sẽ cần biết collection đã “stable” chưa.

Giải pháp: Thêm vào collection_registry hoặc metadata liên quan:

migration_state = unclassified | classified | pilot | stable

🟡 `record_id` trong audit queue kiểu text là thực dụng, nhưng nên có thêm `record_key_type`

Vấn đề: Một số bảng dùng code, một số dùng id, một số natural key.

Lý do: Nếu chỉ có record_id text, sau này truy vết sẽ lẫn giữa id, code, collection.field_name.

Giải pháp: Thêm field nhỏ:

record_key_type = id | code | natural_key

Không bắt buộc trước pilot, nhưng nên có.

5) Nếu deploy pilot ngày mai — bước đầu tiên là gì?

🔴 Bước đầu tiên phải là “đóng contract metadata”, không phải viết trigger ngay

Vấn đề: Nếu ngày mai lao vào trigger trước, đội sẽ code theo hiểu ngầm.

Lý do: Toàn bộ pilot phụ thuộc vào map + mode + source_kind + audit contract. Sai contract thì trigger càng viết nhanh càng sai nhanh.

Giải pháp: Bước đầu tiên ngày mai phải là:

Tạo và đóng băng schema contract tối thiểu cho 4 bảng/cấu phần:

entity_species
species_collection_map
entity_audit_queue
metadata bổ sung trong collection_registry cho storage_role / governance_role / source_kind / migration_state / gate_mode

Sau khi 4 contract này đóng băng mới viết trigger pilot cho dot_tools, entity_labels, directus_fields.

6) Phán quyết cuối

🟢 Phán quyết

v0.4 đủ để pilot.

Không cần kéo dài review lớn thêm. Chỉ cần sửa 3 điểm cụ thể trước khi code:

Mở rộng species_collection_map cho discriminator phức tạp
Biến 3 mode Cổng 2 thành tiêu chí metadata testable
Viết lại rule overlay ontology theo dạng có thể kiểm tra đúng/sai

Nếu 3 điểm này được chèn vào v0.4, tôi ủng hộ đóng băng và pilot ngay.