Incomex AI Portal
KB-7064

GPT Review Lần 2 — Điều 0 v2.0 + Điều 0-B v3.0 (2026-03-13)

10 min read Revision 1

GPT Review Lần 2 — Điều 0 v2.0 + Điều 0-B v3.0

Ngày: 2026-03-13 Nguồn: Incomex Hội đồng AI (GPT) Phạm vi: Review round 2, KHÔNG sửa tài liệu gốc

Tài liệu đã đọc

  1. knowledge/dev/architecture/composition-level-law.md — Điều 0-B v3.0
  2. knowledge/dev/architecture/information-atom-law.md — Điều 0 v2.0
  3. knowledge/dev/planning/review-composition-level-law.md — Yêu cầu review round 2
  4. knowledge/dev/architecture/index.md — Hiến pháp (qua search context)

Kết luận tổng quát

Round 2 tốt hơn round 1 rất nhiều. Hướng hoà giải Điều 0 = nhận diện, Điều 0-B = phân tầng cấu tạo là đúng. identity_class + composition_level cũng là cặp field đúng.

Tuy nhiên hiện vẫn còn một mâu thuẫn nội bộ rất lớn trong chính Điều 0 v2.0: phần đầu đã đổi thuật ngữ sang “thực thể được quản trị”, nhưng nhiều đoạn thân bài vẫn giữ nguyên logic cũ “mọi entity có ID đều là nguyên tử”, thậm chí ghi rõ WF/CPS/M “cũng là nguyên tử”. Nghĩa là ý định hoà giải đã đúng, nhưng văn bản Điều 0 chưa sạch hoàn toàn.

1. Hoà giải Điều 0 + 0-B đã rõ chưa? Còn mâu thuẫn?

Điểm đã rõ

  • Điều 0-B v3.0 viết rất rõ ở phần mở đầu và bảng vai trò:
    • Điều 0 trả lời: thứ này có được quản trị không?
    • Điều 0-B trả lời: thứ này thuộc tầng nào?
  • Field identity_class và composition_level tách đúng hai trục.
  • Câu “Mọi nguyên tử, phân tử, hợp chất đều là thực thể được quản trị. Nhưng không phải mọi thực thể đều là nguyên tử” là câu chốt đúng.

Mâu thuẫn còn lại

Mâu thuẫn nằm ở Điều 0 v2.0 chưa được dọn sạch nội dung legacy:

Mâu thuẫn A — Tiêu đề/định nghĩa mới nhưng thân bài còn logic cũ

Điều 0 đã đổi sang “Thực thể Được Quản trị”, nhưng ngay trong các phần sau vẫn còn:

  • bảng so sánh ghi “Nguyên tử = Entity có ID (PREFIX-NNN)”
  • đoạn ranh giới quản lý ghi “NGUYÊN TỬ (Atomic — CÓ ID PREFIX-NNN)” và liệt kê cả ND, WF, CPS, M
  • đoạn insight nói rõ phân tử và hợp chất cũng là nguyên tử

Như vậy, round 2 đã hoà giải ở tầng tuyên bố, nhưng chưa hoà giải sạch ở tầng nội dung chi tiết.

Mâu thuẫn B — Hướng dẫn cho agent vẫn dùng chữ “nguyên tử” theo nghĩa cũ

Trong Điều 0 phần VI, agent được yêu cầu trả lời:

  1. “Tôi đang thao tác trên NGUYÊN TỬ nào?”
  2. “Nguyên tử này thuộc NGUYÊN TỐ nào?”

Nếu áp dụng v2.0 mới, câu này phải hiểu theo “managed entity”, không còn đúng khi thao tác trên WF/TSK/WCR vì chúng không phải atom tầng 1 nữa.

Phán quyết cho câu 1

  • Về mô hình: đã rõ hơn nhiều, đúng hướng.
  • Về văn bản pháp lý thực tế: chưa sạch hoàn toàn, vì Điều 0 còn nhiều đoạn tự phủ định Điều 0-B.

2. Phân loại 5 atom + 8 molecule + 4 compound — sai chỗ nào?

Tôi đồng ý phần lớn với 5 atom

  • CP: đúng là atom
  • DOT: đúng là atom
  • AGT: đúng là atom
  • CMT: đúng là atom
  • DEP: tạm chấp nhận là atom, nhưng đây là loại dễ gây tranh luận nhất

Điểm cần cảnh giác: DEP

DEP đang được gọi là “1 quan hệ đơn, có metadata riêng”. Điều này ổn nếu coi nó là managed relation record. Nhưng về mặt bản chất, DEP là mô hình của liên kết, không phải “vật thể độc lập” như CP hay DOT.

Tôi không phản đối xếp DEP vào atom, nhưng cần khóa rõ một câu pháp lý kiểu:

  • DEP là atom loại quan hệ (relation-atom), không phải atom nội dung (content-atom).

Nếu không, sau này đội dev sẽ hỏi vì sao junction relation không là atom nhưng DEP lại là atom.

8 molecule

  • COL: đúng
  • TBL: đúng
  • CPS: đúng
  • TP: đúng
  • ND: đúng trong trạng thái hiện tại nhờ bảng edge-case
  • PG: đúng trong trạng thái hiện tại nhờ bảng edge-case
  • CPI: tạm ổn nhưng cần định nghĩa chặt hơn
  • CAT: là mục tôi thấy yếu nhất trong nhóm molecule

CAT là chỗ đáng nghi nhất

Mô tả hiện tại: “Danh mục hệ thống | Metadata per loại”. Nếu mỗi CAT record chỉ là một định nghĩa danh mục đơn, thì nó rất giống atom hơn molecule. Để giữ CAT ở molecule, cần chứng minh nó chứa một tập atom hoặc tổ chức atom chứ không chỉ là “một record metadata”.

Nói ngắn: CAT là entity tôi thấy phân loại yếu nhất hiện tại.

CPI còn hơi mờ

Nếu CPI chỉ là “CP gắn vào context” thì molecule hợp lý. Nhưng nếu mỗi CPI có evidence, result, reviewer, timestamps, state transition riêng thì CPI có thể tiến gần tới compound nhỏ hoặc atom-instance đặc biệt. Hiện mô tả chưa đủ để chốt tuyệt đối.

4 compound

  • WF: đúng
  • TSK: đúng
  • WCR: đúng, tốt hơn round 1
  • M: đúng khi là module có orchestration

Riêng M vẫn phụ thuộc vào kỷ luật edge-case decision. Vì Điều 0-B đã cho phép “module presentational = molecule”, nên phân loại hiện tại không sai, nhưng cần enforcement tốt để không gắn mọi M-* mặc định thành compound nếu thực tế chỉ là wrapper UI.

Phán quyết cho câu 2

  • Không thấy sai nghiêm trọng ở WF/TSK/WCR.
  • Hai điểm yếu nhất hiện nay là CAT và CPI.
  • DEP chấp nhận được, nhưng phải ghi rõ nó là atom của quan hệ, không phải atom nội dung.

3. Field approach (Directus quản lý sẵn, không FLD prefix) — lỗ hổng?

Tôi đồng ý với quyết định không tạo FLD prefix trên directus_fields. Đây là hướng Assembly First đúng.

Điểm mạnh

  • Không đụng system table của Directus
  • Không tạo conflict cache / behavior nội bộ
  • Không phình governance giả tạo cho hàng trăm field system
  • Hợp lý khi Layer 3 field hiển thị bulk per collection thay vì per-field page

Lỗ hổng còn lại

Lỗ hổng A — Field được gọi là atom nhưng lại không thoả đầy đủ Điều 0

Điều 0 yêu cầu managed entity phải có:

  • ID duy nhất
  • registry
  • metadata
  • 8 quan hệ
  • Lớp 3 riêng

Nhưng field approach mới lại nói:

  • không PREFIX
  • không page per-field
  • quản bulk

Vậy field không còn là “thực thể được quản trị” đầy đủ theo Điều 0, mà là atomic resource được Directus quản trị sẵn. Đây là hướng thực dụng đúng, nhưng phải gọi tên cho chuẩn. Nếu không sẽ phát sinh câu hỏi:

  • “Field là atom của Điều 0-B hay là managed entity của Điều 0?”

Theo tôi, câu trả lời hợp lý nhất là:

  • Field là atom cấu tạo theo Điều 0-B
  • nhưng không phải managed entity chuẩn Điều 0 ở mức per-field record
  • nó được quản trị theo bulk/native-system governance

Nếu không khóa câu này, logic identity sẽ bị thủng.

Lỗ hổng B — Natural key collection + field_name chưa đủ cho mọi biến thể

Natural key này ổn cho uniqueness, nhưng chưa chắc đủ cho lifecycle/audit dài hạn nếu:

  • field rename
  • drop + recreate cùng tên
  • shadow field giữa môi trường

Không phải lý do để tạo FLD prefix, nhưng cần thêm policy về field identity continuity khi rename/migrate.

Lỗ hổng C — “Focus 400-500 fields nghiệp vụ” là rule vận hành, chưa phải rule pháp lý

Hiện đây giống assumption quản trị hơn là định nghĩa hệ thống. Cần cẩn thận để khỏi rơi vào tình trạng:

  • hôm nay 500 field nghiệp vụ
  • mai 1200 field nghiệp vụ
  • luật không nói rõ cách co giãn governance

Phán quyết cho câu 3

  • Hướng này đúng và thực tế.
  • Nhưng cần chốt rõ: Field là atom cấu tạo native-managed, không phải managed entity đầy đủ theo Điều 0.
  • Nếu không, Điều 0 và Điều 0-B sẽ lại lệch nhau ở riêng case Field.

4. Còn thiếu gì để triển khai?

Thiếu 5 thứ then chốt.

(1) Dọn sạch Điều 0 khỏi nội dung legacy

Đây là việc số 1. Không dọn, team sẽ đọc một luật thấy “WF không phải atom”, luật kia lại thấy “WF cũng là atom”.

(2) Decision matrix cho CAT, CPI, DEP

ND/PG/M đã có edge-case table. Nhưng thực tế round 2 cho thấy 3 loại còn mờ là:

  • CAT
  • CPI
  • DEP

Ba loại này cũng cần bảng phân xử hoặc chú giải pháp lý ngắn.

(3) Định nghĩa rõ 3 lớp quản trị khác nhau

Hiện đang có ít nhất 3 kiểu đối tượng khác nhau nhưng chưa gọi tên tách bạch:

  1. Managed entity chuẩn — có ID, registry, Layer 3 riêng
  2. Native-managed atomic resource — như Field, do Directus quản lý sẵn
  3. Sub-atomic system artifact — values, revisions, config JSON

Không tách 3 lớp này, implementation sẽ lẫn.

(4) Rule migrate khi entity đổi tầng

Điều 0-B đã cho phép ND/PG/M nâng cấp tầng khi complexity tăng. Tốt. Nhưng còn thiếu cơ chế:

  • ai phê duyệt đổi tầng
  • đổi tầng có cần migration audit không
  • Layer 3 contract thay đổi ra sao
  • dashboards/count histories có backfill hay không

(5) Contract triển khai cho Layer 3 theo từng tầng

Round 2 đã nói khác nhau theo tầng, nhưng để bắt đầu triển khai thật cần ít nhất 1 schema contract cụ thể:

  • atom card có gì
  • molecule card có gì
  • compound card có gì
  • field bulk panel có gì

Nếu chưa có contract, dev vẫn phải tự đoán.

Trả lời ngắn 4 câu hỏi

1. Hoà giải Điều 0 + 0-B đã rõ chưa? Còn mâu thuẫn?

  • Ý tưởng hoà giải: rõ.
  • Văn bản thực tế: vẫn còn mâu thuẫn trong Điều 0 do nội dung cũ chưa dọn sạch.

2. Phân loại 5 atom + 8 molecule + 4 compound — sai chỗ nào?

  • Tổng thể hợp lý.
  • Điểm cần soi kỹ nhất: CAT, kế đó CPI, rồi DEP.

3. Field approach — lỗ hổng?

  • Hướng đúng.
  • Lỗ hổng chính: field đang là atom cấu tạo nhưng không còn khớp hoàn toàn với định nghĩa managed entity của Điều 0. Cần tuyên bố rõ nó là native-managed atomic resource.

4. Còn thiếu gì để triển khai?

  • Dọn sạch Điều 0 legacy
  • Decision matrix cho CAT/CPI/DEP
  • Tách rõ 3 lớp quản trị
  • Rule migrate khi đổi tầng
  • Contract Layer 3 theo từng tầng

Phán quyết cuối

  • Round 2 đạt tiến bộ lớn, gần mức có thể triển khai.
  • Chưa nên coi là đóng hoàn toàn, vì còn một mâu thuẫn pháp lý ngay trong Điều 0 và một lỗ hổng định nghĩa quanh Field.
  • Nếu xử lý xong 2 điểm đó, tôi xem đây là nền đủ chắc để bắt đầu triển khai thực tế.