Kế hoạch Truth Probe tối giản cho Registries: PG → Nuxt để bắt sai số hệ thống nhiều tầng

• Thời điểm: 2026-03-25
• Agent: Incomex Hội đồng AI
• Mục tiêu: không thay thế hệ thống phức tạp hiện có; tạo một đường kiểm chứng độc lập, cực đơn giản để nếu hệ thống đếm sai thì lộ ngay trên Nuxt.

Ý tưởng cốt lõi

Đây không phải dashboard aggregate thông thường. Đây là canary / truth probe theo tinh thần Điều 31:

• Chân lý nằm ở PG SSOT
• Nuxt chỉ hiển thị lại đúng con số từ PG
• Dùng con số này để so chéo với hệ thống nhiều tầng hiện tại
• Nếu lệch => biết ngay hệ thống đang lỗi hoặc contract đang sai

Thiết kế khuyên dùng

1) Tạo 1 PG function cực ngắn, cực rõ nghĩa

Ví dụ:

• fn_registry_truth_probe()
• Trả đúng 1 row
• Chỉ gồm vài trường:
  • atomic_total
  • composite_total
  • governed_total
  • generated_at

Logic của function phải bám đúng Hiến pháp/Luật hiện hành:

• nguyên tử = entity có prefix chuẩn
• không đếm log records/changelog/system_issues vào tổng nguyên tử
• count trực tiếp từ PG, không phụ thuộc Directus UI logic, không phụ thuộc registry cache

2) Tạo 1 đường hiển thị tối giản lên Nuxt

Khuyên dùng 1 trong 2 cách:

• Cách A (đúng luật, ít rủi ro): expose function/view read-only qua Directus rồi Nuxt fetch đúng endpoint đó
• Cách B (nếu cần độc lập hơn để kiểm chứng): Nuxt server API read-only gọi thẳng PG function

3) Gắn 1 ô nhỏ trên trang Registries

Ví dụ:

• PG Truth: 754
• System Count: 752
• badge: KHỚP / LỆCH +2

Đây là “ô báo động”, không phải thay toàn bộ bảng.

Vì sao cách này đúng với bài toán

User không muốn thêm phức tạp. User muốn một phép tính đơn giản, đáng tin, khó cãi.

Vậy nguyên tắc là:

• đường kiểm chứng phải ngắn hơn đường hệ thống chính
• ít tầng hơn
• ít nơi có thể sai hơn
• và nhìn phát biết lệch

Cơ sở pháp lý/kiến trúc

1. Điều 31 — PG vs Nuxt: contract hợp lệ là lấy chân lý từ PG rồi so với Nuxt/UI. Đây chính là bài toán loại B.
2. Single Provider (Điều 0-S): PG function truth probe là 1 nơi cung cấp chân lý kiểm chứng.
3. Assembly First: chỉ thêm 1 function + 1 ô UI + tối đa 1 endpoint mỏng.
4. Luật kết nối dữ liệu: ưu tiên read-only view/function chuẩn, tránh logic rải ở frontend.

Khuyến nghị triển khai

Bản tối thiểu nhất

• 1 PG function fn_registry_truth_probe()
• 1 Nuxt endpoint mỏng /api/registry/truth-probe
• 1 badge/card nhỏ trên /knowledge/registries
• 1 compare line với số hiện hệ thống đang show

Không nên làm

• Không dùng chính pipeline đếm phức tạp hiện tại để tự xác minh chính nó
• Không SUM ở frontend
• Không reuse nhiều lớp cache/registry nếu mục tiêu là kiểm chứng độc lập

Kết luận

Nếu mục tiêu là “đề phòng cái đống phức tạp đếm sai”, thì giải pháp đúng không phải làm thêm 1 hệ aggregate nữa.

Giải pháp đúng là tạo 1 Truth Probe tối giản từ PG lên Nuxt để làm số đối chứng thường trực.

Khi PG Truth != System Count => coi như có tín hiệu lỗi ngay, rồi mới truy nguyên tầng nào sai.