Incomex AI Portal
KB-12AE

GPT Review — S116 Count Definitive Plan (2026-03-13)

6 min read Revision 1

GPT Review — S116 COUNT DEFINITIVE

Ngày: 2026-03-13 Nguồn: Incomex Hội đồng AI (GPT) Phạm vi: Rà soát kế hoạch đếm, tài liệu architecture, và prompt triển khai S116

Tài liệu đã rà soát

  • Điều 0: Luật Thực thể Được Quản trị
  • Điều 0-B: Luật Phân tầng Cấu tạo Vật chất Thông tin v3.1
  • Hiến pháp kiến trúc (context)
  • REGISTRY-ENGINE plan/report
  • Mission S108-REGISTRY-PG Report
  • Mission S111-COUNT-VERIFY Report
  • Mission E Report
  • Mission E-FIX Report
  • urgent-s112-agent-directive
  • meta_catalog/CMT

Kết luận ngắn

Kế hoạch S116 đúng hướng hơn hẳn các mission trước, và nếu làm đúng sẽ tiến gần bộ đếm tin cậy. Nhưng hiện vẫn CHƯA đủ để đảm bảo “đếm đúng, realtime, ổn định dài hạn”. Cần bổ sung 6 điểm khóa dưới đây.

Vì sao cách cũ thất bại

  1. Dùng nhiều số (count_a/count_b/count_c/baseline) nhưng không khóa nghĩa pháp lý của từng số.
  2. Crosscheck so các số đã refresh cùng lúc nên có thể “khớp giả”.
  3. Dùng refresh thủ công/cron nên số hiển thị không phải thời gian thực.
  4. Danh sách loại cần đếm không bám chặt vào meta_catalog identity_class='managed' + trạng thái kiến trúc.
  5. CMT mới sinh nhưng pipeline đếm không tự bắt được.

Đánh giá kế hoạch S116 hiện tại

Điểm mạnh

  • Bỏ count_b/count_c/cross_check là đúng.
  • Chuyển sang record_count + orphan_count là đúng hướng.
  • Trigger per collection để cập nhật ngay là đúng hơn cron refresh.
  • verify_counts() live query là đúng tư duy kiểm chứng.
  • 1 bảng duy nhất trên Nuxt là đúng, dễ đọc hơn cards.

Chưa đủ / cần bổ sung bắt buộc

1. Phải verify orphan live, không chỉ verify record_count

Prompt hiện chỉ mô tả verify_counts() so stored_count với live_count. Nhưng yêu cầu của user là mồ côi cũng phải tin cậy.

Cần đổi thành hàm verify trả về cả 2 cặp:

  • stored_count vs live_count
  • stored_orphan_count vs live_orphan_count

Nếu chỉ verify count mà không verify orphan, hệ vẫn có thể hiện đúng số lượng nhưng sai mồ côi.

2. Phải có schema audit gate cho 17 managed collections trước khi tạo trigger

Prompt có nói “verify tên PG table thực tế”, nhưng chưa biến nó thành kiểm chứng cứng.

Cần thêm 1 bước/hàm audit bắt buộc xác nhận cho từng managed type:

  • có row trong meta_catalog
  • có collection_name thật
  • table thật sự tồn tại trong PG
  • với managed entity chuẩn: có cột code
  • có unique/identity invariant cho code

Nếu không có audit gate này, agent vẫn có thể viết trigger vào sai table hoặc đếm 0 mà tưởng đúng.

3. Phải kiểm tra TRUNCATE, không chỉ INSERT/DELETE/UPDATE

Prompt hiện tạo trigger cho INSERT + DELETE + UPDATE. Để ổn định dài hạn, cần thêm TRUNCATE ở statement level. Nếu có thao tác dọn bảng/test seed bằng TRUNCATE, bộ đếm sẽ lệch mà không tự hồi phục.

4. Phải khóa rõ: UI hiển thị số nào là số chính thức

Hiện plan vẫn hơi mơ hồ giữa:

  • v_registry_counts.record_count (cache do trigger cập nhật)
  • verify_counts.live_count (đếm sống)

Khuyến nghị:

  • record_count = số chính thức hiển thị trên bảng
  • verify_* = lớp xác minh độc lập
  • nếu mismatch thì hiện ❌ ngay

Nhưng phải viết rõ trong prompt để Opus không lại trộn 2 nguồn.

5. Phải có mapping động từ meta_catalog, không hardcode 17 mãi mãi

S116 có thể làm cho 17 loại hiện tại, nhưng nếu muốn ổn định dài hạn thì verify_counts() và seed rows cho bảng counts phải đọc từ:

  • meta_catalog
  • identity_class='managed'
  • status hợp lệ

Nếu vẫn hardcode 17 loại trong function, lần sau thêm managed type mới sẽ lại sinh “không ai đếm”.

6. Cần phân biệt đúng 3 lớp quản lý khi đếm

Theo Điều 0-B v3.1:

  • Managed Entity chuẩn → đếm trong bảng chính 5+8+4
  • Native-managed Resource → ví dụ Field, đếm riêng, không gộp vào tổng 17 managed collections
  • Sub-atomic → không đếm registry-level

Prompt hiện đã tập trung 17 managed collections là đúng, nhưng nên ghi thêm 1 câu khóa cứng để Opus không vô tình kéo directus_fields, logs, activity vào cùng tổng như các mission cũ.

3 bổ sung quan trọng cho prompt của Opus

  1. Thêm test orphan live:

    • SELECT * FROM verify_counts() WHERE stored_orphan_count <> live_orphan_count; → 0 rows

  2. Thêm test schema integrity trước khi làm:

    • đủ 17 managed rows từ meta_catalog
    • đủ 17 PG tables thật
    • đủ 17 code columns cho managed standard collections

  3. Thêm test trigger coverage:

    • 17 trigger count
    • nếu có managed collection mới trong meta_catalog mà chưa có trigger → FAIL CI

Đánh giá prompt hiện tại: đã đủ chưa?

Chưa đủ.

Đã đủ cho:

  • sửa mô hình đếm sai hiện tại
  • bỏ crosscheck giả
  • đưa hệ về realtime gần đúng

Chưa đủ cho “tin cậy, ổn định dài hạn” vì còn thiếu:

  • verify orphan live
  • schema audit gate
  • TRUNCATE coverage
  • mapping động từ meta_catalog
  • quy định rõ nguồn số chính thức trên UI

Chốt kiến nghị

Nếu muốn có bộ đếm thật sự tin cậy, ổn định dài hạn, tôi đề nghị S116 chỉ được coi là DONE khi có đủ 4 lớp:

  1. Count cache: record_count, orphan_count
  2. Live verify: live count + live orphan
  3. Schema audit: table/code/trigger coverage cho mọi managed collection
  4. CI guard: collection managed mới xuất hiện mà chưa được đếm → fail ngay

Phán quyết

  • Phương pháp S116: ĐÚNG HƯỚNG
  • Prompt hiện tại: CHƯA ĐỦ
  • Cần bổ sung 6 điểm trên trước khi giao Opus triển khai, nếu không rất dễ lặp lại vòng “sửa đúng một lúc rồi lệch lại”.