GPT Review Round 2 — Điều 31 v1.1: Luật Toàn Vẹn Hệ Thống

Ngày: 2026-03-23 Vai trò: Hội đồng Kiến trúc AI — phản biện vòng 2 Tài liệu đã đọc qua Agent Data:

knowledge/dev/architecture/system-integrity-law.md (v1.1)

knowledge/dev/architecture/regression-protection-law.md (Điều 30 v1.2)

knowledge/dev/architecture/design-feasibility-formula.md

knowledge/dev/architecture/species-taxonomy-complete.md

knowledge/dev/architecture/dot-scanning-system.md

knowledge/dev/architecture/index.md (đọc qua search context)

Kết luận ngắn

GO cho v1.1.

Bản v1.1 đã tích hợp đúng phần lớn các yêu cầu blocking của vòng 1. Tôi không còn thấy blocker kiến trúc đủ mạnh để giữ ở mức Conditional GO. Từ thời điểm này, rủi ro lớn nhất không nằm ở bản luật nữa mà nằm ở việc pilot có bị làm quá rộng hoặc làm sai thứ tự không.

G1. Các điểm vòng 1 đã được xử lý đầy đủ chưa?

Đánh giá: Xử lý đúng và khá đầy đủ. Không còn điểm nào bị hiểu sai nghiêm trọng.

Đã tích hợp đúng

Contract validation được nâng lên thành một lớp riêng trước runner
Coverage metrics đã được formal hóa thành 3 chỉ số bắt buộc
Dedupe engine có fingerprint, reopen, occurrence_count
Điều 30 ↔ 31 đã được tách bằng môi trường/trigger/artifact/outcome
Có health gate và 2-pass verify để giảm false positive
Có event-triggered recheck để khép kín hơn
INFO pass không còn đổ vào system_issues
Dòng 11 không còn là điểm phơi bày duy nhất

Còn 2 điểm hơi mỏng nhưng không còn là blocker

Ngưỡng coverage của pilot chưa gắn rõ với hành động nếu không đạt.
Aggregation rule trong dedupe mới nêu nguyên tắc, chưa nói rõ ranh giới khi nào gom và khi nào giữ tách.

G2. Contract Schema (§4.2) có đủ fields bắt buộc chưa? Semantic validation cần gì thêm?

Đánh giá: Gần đủ cho pilot, nhưng nên thêm 4 field/validation nhỏ để tránh nợ kỹ thuật sớm.

Nên có thêm trong contract hoặc semantic validation

enabled — bật/tắt contract/check có chủ đích, tránh xóa tay
grace_seconds per check — thay vì hardcode 60s cho mọi WARNING
source_of_truth — PG / Directus API / Agent Data / Contract để runner và điều tra rõ nguồn
blast_radius hoặc scope — page / collection / system-wide để triage tốt hơn

Semantic validation nên thêm

owner phải map được tới user/agent hợp lệ
page_url của Tier A phải tồn tại trong route map hoặc preview build
dom_vs_db phải có cả selector + query
directus_vs_vector phải có direction
strict_equals không được dùng cho nguồn known-eventual nếu contract có gắn grace
last_verified_at quá cũ → warning “contract stale”

Kết luận: Đủ để pilot, nhưng nên thêm enabled và grace_seconds ngay nếu chi phí rất thấp.

G3. Issue Dedupe (§4.7) với violation_hash + aggregation — có edge case nào bị bỏ sót?

Có 4 edge case nên chốt thêm:

Cùng check_id nhưng giá trị sai khác khác nhau theo thời gian
- Nếu fingerprint chỉ dùng contract_id + check_id + class thì mọi mismatch khác nhau sẽ bị gom quá mạnh.
- Đề xuất: fingerprint giữ như hiện tại là đúng cho reopen, nhưng evidence snapshot phải giữ latest_value + sample_values + max_delta.
Một lỗi infra kéo theo hàng loạt check fail
- Health gate đã chặn phần lớn, nhưng nếu API partial-down vẫn có thể sinh issue cascade.
- Đề xuất: nếu 1 source chung fail diện rộng trong cùng run → tạo 1 parent issue infra/sync, child checks chỉ ghi artifact chứ không tạo issue riêng.
Aggregation quá tay làm mất khả năng sửa đúng chỗ
- Gom theo Species/Collection là đúng, nhưng không nên gom chéo root cause khác nhau.
- Đề xuất: chỉ aggregate khi cùng issue_class + source_system + page_url/collection + run_id.
Reopen issue cũ sau thời gian dài nhưng logic đã đổi
- Contract version đổi mà vẫn reopen issue cũ có thể sai ngữ cảnh.
- Đề xuất: fingerprint hoặc reopen rule nên tính đến contract_version major.

Kết luận: Dedupe engine đã đủ tốt cho pilot, nhưng nên khóa 2 rule: parent issue cho incident diện rộng và reopen theo contract major version.

G4. Coverage Metrics (§4.8) — 3 chỉ số và ngưỡng tối thiểu có hợp lý cho giai đoạn pilot?

Hợp lý cho pilot, nhưng cần tách “target” và “gate”.

Tôi đồng ý với 3 chỉ số

Page Coverage
Invariant Coverage
Runtime Pass Rate

Nhưng ngưỡng nên hiểu như sau

Tier A Page Coverage 100% = gate cứng cho pilot
Invariant Coverage ≥ 80% = target tốt, chưa nên gate cứng trong tuần đầu pilot
Runtime Pass Rate ≥ 95% = đúng làm health threshold, nhưng nên đo sau khi loại infra_down và quarantined known flaky cases

Đề xuất wording

Page Coverage = gate
Invariant Coverage = target có backlog tăng dần
Runtime Pass Rate = health KPI

Nếu biến cả 3 thành gate cứng ngay từ đầu, pilot dễ bị kẹt vì coverage debt thay vì runtime integrity.

H5. Tích hợp DOT Scanning (§VI): Việc gom Điều 23 vào Điều 31 có tạo conflict hay overlap không mong muốn không?

Không tạo conflict nếu giữ đúng ranh giới hiện tại trong v1.1.

Bản v1.1 xử lý khá đúng:

Điều 23 = nguyên tắc tổ chức quyền lực kiểm tra độc lập
Điều 31 = cơ chế contract/runner/issue để thực thi các kiểm tra đó

Đây là quan hệ hợp lý kiểu:

Điều 23 trả lời: ai được kiểm tra và triết lý kiểm tra là gì?
Điều 31 trả lời: kiểm tra bằng cái gì, chạy khi nào, issue đi đâu?

Điểm cần tránh

Không nên viết theo hướng “Điều 31 thay thế Điều 23”. Hiện draft không đi quá đà, nên ổn.

Đề xuất nhỏ

Thêm 1 câu khóa:

“Điều 23 là nguyên tắc phân quyền kiểm tra độc lập; Điều 31 là framework vận hành các kiểm tra đó dưới dạng contracts và runners. Điều 31 không làm mất hiệu lực Điều 23.”

H6. Directus ↔ Agent Data integrity (§VI.3): Contract mẫu CTR-SYNC-001 có thực tế không? Cần điều chỉnh gì?

Thực tế, đúng hướng, và nên giữ trong pilot.

Điểm đúng

Chọn kiểm tra hai chiều là đúng bài học từ sự cố mất document/vector orphan
Đưa nó vào cùng framework contract giúp không tạo hệ kiểm tra song song mới

Nhưng cần chỉnh 3 điểm

collections: ["knowledge_documents", "registry_*"] còn hơi mơ hồ
- wildcard trong contract phase đầu dễ làm runner phức tạp
- Đề xuất: pilot dùng danh sách explicit, chưa dùng wildcard
Chiều A (Directus → Vector) cần thêm trạng thái trung gian
- có record mới nhưng flow chưa chạy xong không nên báo ngay là mismatch
- Đề xuất: dùng eventual_equals + grace_seconds cho chiều A
Chiều B (Vector → Directus) nên kiểm tra theo source_id/source_collection/source_pk
- không chỉ check “có record nào đó không”, mà phải check tham chiếu gốc đủ 3 thành phần

Kết luận: Contract mẫu thực tế, nhưng nên explicit collections và thêm grace/state semantics.

H7. Kiểm tra HAI CHIỀU (Directus→Vector và Vector→Directus) — severity phân bổ (WARNING vs CRITICAL) có hợp lý?

Cơ bản là hợp lý.

Tôi đồng ý với logic hiện tại

Directus có, vector thiếu = thường là WARNING
- vì có thể do sync delay / queue / flow chưa chạy
Vector có, Directus không có = thường là CRITICAL
- vì đây là orphan mất nguồn gốc, rất nguy hiểm cho trust

Nhưng cần 1 ngoại lệ rõ

Nếu collection đó được đánh dấu là:

must_sync_realtime=true, hoặc
loại dữ liệu legal/compliance/knowledge-critical,

thì chiều A fail quá grace_seconds hoặc quá SLA cũng phải nâng từ WARNING → CRITICAL.

Đề xuất: severity base theo draft, nhưng cho phép contract override theo collection class/SLA.

I8. Với 23 điểm sửa, v1.1 có bị "phình" quá mức cho pilot không? Cần cắt bớt gì?

Không bị phình quá mức. Bản v1.1 đã lớn hơn nhưng vẫn còn trong ngưỡng pilot hợp lý, vì phần lớn là “siết nghĩa”, không phải thêm hệ thống mới.

Không nên cắt

Contract Schema
Coverage Metrics
Dedupe
Health Gate
Điều 30↔31 boundary
CTR-SYNC-001 pilot

Có thể hoãn nhẹ nếu cần giảm áp lực triển khai

Coverage dashboard trên Nuxt có thể hoãn sau artifact/report trước
Aggregation nâng cao có thể làm phiên bản đơn giản trước
Deep Audit full PG raw vs API vs DOM vs Agent Data có thể để manual phase đầu

Kết luận: Không cần cắt luật. Chỉ cần cắt tham vọng triển khai UI/report nếu đang thiếu lực.

I9. Thứ tự triển khai 4 blocking items (contract validation, coverage, dedupe, ranh giới 30↔31) — ưu tiên item nào trước?

Thứ tự tôi khuyên:

Contract validation
- vì không có nó, mọi thứ sau có thể chạy trên nền contract sai
Ranh giới 30 ↔ 31
- vì nếu không tách sớm, runner/test sẽ lẫn preview với production, artifact lẫn lộn
Dedupe
- vì issue storm sẽ giết pilot rất nhanh nếu không có fingerprint/reopen
Coverage metrics
- quan trọng, nhưng pilot vẫn có thể chạy thiếu dashboard hoàn chỉnh trong vài ngày đầu nếu 3 món trên đã có

Nói ngắn gọn

Validation = chống kiểm tra sai
Boundary = chống làm sai môi trường
Dedupe = chống chết vì quá nhiều issue
Coverage = để biết còn thiếu gì

I10. Phán quyết cuối: GO / CONDITIONAL GO / NO-GO cho v1.1?

Không còn blocker kiến trúc đủ mạnh để giữ lại. Những gì còn lại là chi tiết triển khai/pilot hygiene, không phải sai mô hình.

Điều kiện ngầm để GO này đúng

Pilot thật sự giữ hẹp: CTR-001, CTR-002, CTR-003, CTR-SYNC-001
Không mở rộng Tier B/C ngay tuần đầu
Không biến dashboard coverage thành blocker trước khi validation + boundary + dedupe chạy ổn

GỢI Ý BỔ SUNG

1. Thêm `run_id` vào evidence và dedupe context

Để trace issue về đúng lần chạy post-deploy/cron/event.

2. Thêm `stale_contract_days`

Nếu last_verified_at quá N ngày → tạo WARNING contract_fault riêng. Không để contract già mà không ai biết.

3. Không đưa pass INFO vào Directus

Draft đã đúng. Hãy giữ rất chặt nguyên tắc này.

4. Pilot report nên có 1 bảng cực ngắn

contract loaded
checks run
issues new
issues reopened
pass rate
coverage

5. Khi làm CTR-SYNC-001, nên bắt đầu bằng 1-2 collections thật sự quan trọng

Đừng quét quá rộng ngay từ đầu. Ví dụ:

knowledge_documents
1 registry collection cốt lõi

Kết luận cuối

Điều 31 v1.1 đã đủ chín để GO.

Từ đây, giá trị lớn nhất không còn nằm ở viết lại luật mà ở triển khai pilot đúng thứ tự, giữ phạm vi hẹp, và đo dữ liệu thật từ 1-2 tuần đầu chạy cron/post-deploy/event recheck.