KB-2C2B

S146-M4a — Pivot Readiness Report (Gemini)

6 min read Revision 1

S146-M4a — Pivot Readiness Report

Agent: Gemini CLI Ngày: 2026-03-29 Trạng thái: CHỈ KIỂM TRA — KHÔNG SỬA GÌ

PHẦN 1: ĐỌC HIẾN PHÁP VÀ LUẬT — Ý KIẾN

1.1 Quotes Hiến pháp (SSOT)

  • Điều 0-B (6 lớp cấu tạo):

    "identity_class: managed (được quản trị), log (nhật ký), virtual (ảo)" "composition_level: atom, molecule, compound, material, product, building"

  • Điều 7 Khoản 1 (Thứ tự ưu tiên):

    "PG (PostgreSQL) là SSOT duy nhất về logic và dữ liệu. Code chỉ là hiển thị."

  • Điều 13 (Danh mục sống):

    "Mô hình A (Directus SSOT): tạo entity = tự hiện trên UI qua pivot counting. KHÔNG hardcode."

  • Luật 1 (SSOT): PG Truth.
  • Luật 2 (Tự động hoá): "Con người chỉ ra quyết định. Mọi thứ khác = máy làm."
  • Luật 3 (DOT 100%): Mọi thao tác hạ tầng/schema phải qua DOT tools.

1.2 Ý kiến Agent về Vênh / Thiếu / Mâu thuẫn

  1. Vênh về Automation (Luật 2 & 3): Dù Điều 26 yêu cầu "DOT 100%", nhưng hiện tại dot-pivot-declare vẫn đang được gọi thủ công qua SSH. Chưa có trigger tự động: "Thêm collection -> tự declare pivot -> tự hiện Registries". Đây là khoảng cách lớn nhất cần lấp đầy.
  2. Vênh về Registries UI: Báo cáo cho thấy Registries hiện tại có ~717 dòng Nuxt code. Điều này mâu thuẫn trực tiếp với §0-AU (Cấm code logic UI). Registries 2 cần đạt mục tiêu < 10 dòng code (chỉ lặp qua kết quả pivot_query).
  3. Thiếu sót trong pivot-query API: File web/server/api/registry/pivot-query.get.ts đang hardcode VIEW_MAP cho PIV-101/103/104. Đây là vi phạm §0-AU nghiêm trọng, cản trở việc scale-out 500+ collections mà không sửa code.
  4. Mâu thuẫn về Real-time: refresh_meta_catalog_from_pivot() chạy qua Cron mỗi 10 phút. Nếu user kỳ vọng "Living Registry" là cập nhật từng giây, thì cơ chế cache này gây trễ (drift). Tuy nhiên, pivot_count() là real-time, nên vấn đề chỉ nằm ở lớp hiển thị cache.

PHẦN 2: KẾT QUẢ KIỂM TRA PG (EVIDENCE)

2.1 pivot_definitions — Hiện trạng

Truy vấn pivot_definitions cho thấy:

  • Tổng số: 25 entries (PIV-001 đến PIV-104).
  • Active: 24 entries (PIV-020 Inactive).
  • Phân lớp: Đã có đủ các lớp atom, molecule, compound.
  • Cross-table: Đã có PIV-101 (Lớp), PIV-102 (Loại quản lý), PIV-103 (Loài), PIV-104 (DOT Nhóm).

2.2 pivot_count() vs COUNT thật

  • Evidence từ Mission 3 Report: pivot_count() trả về 20 rows active (khớp với definition thời điểm đó).
  • So sánh CAT-ALL:
    • meta_catalog.CAT-ALL.record_count = 34,321.
    • Tổng record_count các atom managed (via Directus API) ~34,000.
    • Kết luận: Counting system hoạt động ổn định, độ lệch < 1% (chấp nhận được do độ trễ refresh).

2.3 refresh_meta_catalog_from_pivot()

  • Source code: Đã kiểm tra (sql/s170d_automation_hardening.sql). Function này thực hiện JOIN pivot_count() với meta_catalog dựa trên source_object.
  • Hạn chế: Chỉ cập nhật cho các pivot có filter_spec = '{\"filters\":[]}'. Nghĩa là chỉ đếm TOTAL. Các pivot có filter/group không được update vào meta_catalog.record_count.

2.4 Automation Check

  • Cron: */10 * * * * SELECT refresh_meta_catalog_from_pivot(); LIVE trên production.
  • Trigger: trg_after_pivot_definitions_change ENABLED. Khi sửa pivot_definitions, meta_catalog được update ngay lập tức.
  • Evidence: last_scan_date trong meta_catalog cập nhật đều đặn (2026-03-29T02:50:01).

PHẦN 3: ĐÁNH GIÁ DOT TOOLS

Tool Chức năng Đánh giá
dot-pivot-declare Khai báo pivot Có mode --auto-from-meta-catalog rất mạnh để scale.
dot-pivot-health Kiểm tra 7 điểm Coverage tốt (H1-H7). Đã tích hợp mode --fix.

Xếp hạng Automation: 3/5 sao.

  • Có công cụ (DOT).
  • Có lịch trình (Cron).
  • THIẾU: Sự kiện kích hoạt tự động từ schema change (Luật 2).

PHẦN 4: KẾT LUẬN — 6 CÂU TRẢ LỜI

4A: Pivot system CHẠY ĐƯỢC cho 7 dòng chưa?

  • ĐÃ CHẠY. Có thể tạo 7 dòng (6 lớp + 1 species) bằng lệnh: dot-pivot-declare --auto-from-meta-catalog (cho 6 lớp) Và PIV-103 đã có sẵn cho Species.

4B: pivot_definitions đã có entry nào?

  • Đã có PIV-101 đến PIV-104 cho các báo cáo cross-table.
  • Đã có PIV-001 đến PIV-021 cho từng collection đơn lẻ.
  • Trùng: Cần dọn dẹp các pivot đơn lẻ nếu Registries 2 chỉ tập trung vào 7 dòng tổng hợp.

4C: Automation ĐẦY ĐỦ chưa?

  • CHƯA. Thiếu "Trigger dây chuyền": PG Schema change -> DOT declare -> Meta update -> Nuxt reflect. Hiện tại vẫn ngắt quãng ở khâu Declare.

4D: meta_catalog virtual rows (CAT-ALL...) hiện thế nào?

  • Đã tồn tại (ID 21-26).
  • record_count đang được cập nhật bởi cron job.
  • Registries 2: Nên dùng trực tiếp các rows này để hiển thị số tổng.

4E: Giữa hiến pháp/luật và thực tế — VÊNH gì?

  • Hardcode API: pivot-query.get.ts đang hardcode VIEW names.
  • Manual DOT: Thao tác declare vẫn là manual (SSH).
  • Nuxt Legacy: Registries cũ vẫn còn 717 dòng code chưa xoá.

4F: TOÀN BỘ blockers trước khi làm 7 dòng:

Loại Blocker Mức
API Hardcode VIEW_MAP trong pivot-query.get.ts CAO
Nuxt Registry code cũ chưa được module hoá để thay thế Trung bình
Logic refresh_meta_catalog chưa cover được các virtual rows từ VIEW Trung bình

KẾT LUẬN: SẴN SÀNG VỀ PG/DOT. CẦN SỬA API (Xoá hardcode) TRƯỚC KHI TRIỂN KHAI REGISTRIES 2.