Điều 31 — Phương Pháp Luận: "Điều Gì Đảm Bảo Nó Đúng?"

Version: v2.0 | Ngày: 2026-03-24 | Session: S132 Tác giả: Anh Huyên (tầm nhìn + phương pháp), Claude Desktop (soạn thảo) SSOT: Tài liệu này là phương pháp luận gốc cho MỌI contract/check trong Điều 31. Tham chiếu: Luật Điều 31 §III-B. Mọi agent viết contract PHẢI đọc tài liệu này.

I. VẤN ĐỀ GỐC

"Cơ quan kiểm tra" (Điều 31) báo lỗi — nhưng làm sao biết nó báo ĐÚNG?

Nếu không trả lời được → kết quả = "cầu Chúa" (Huyên, S132).

Bài học đau thương từ việc đếm: đếm = việc tĩnh, đơn giản nhất, mà 4 tầng code vẫn sai suốt nhiều tuần. Phát hiện lỗi = việc ĐỘNG, phức tạp hơn đếm rất nhiều. Nếu phương pháp luận không chuẩn từ đầu → sa đà vài tuần mà kết quả vẫn không tin cậy → vòng luẩn quẩn y hệt.

"Tất cả những thứ tư duy rắc rối đều là kẻ thù của sự chính xác và tin cậy." (Huyên, S132)

II. NGUYÊN TẮC NỀN TẢNG — CHIA BÀI TOÁN PHỨC TẠP THÀNH 2 BÀI TOÁN ĐƠN GIẢN

Bài toán gốc (PHỨC TẠP, KHÔNG GIẢI TRỰC TIẾP):

"Web có đúng không?" → Rối, không chứng minh được, vì "đúng" so với cái gì?

CHIA thành 2 bài toán ĐƠN GIẢN, mỗi bài TỰ CHỨNG MINH ĐƯỢC:

BÀI TOÁN 1: SSOT TRONG PG CÓ ĐÚNG KHÔNG?

Mục tiêu: PG là nguồn chân lý gốc. SSOT trong PG phải tự đảm bảo đúng.

Cơ chế:

Muốn đếm/giám sát cái gì → TẠO collection trong PG để tự ghi tổng biến động
Collection list rõ: đếm cái gì, bao nhiêu danh mục, bao nhiêu records
Thêm tính năng mới, thêm số mới trên web → Collection PG TỰ MỞ RỘNG THEO
Nếu web mở rộng mà collection KHÔNG mở rộng → đó cũng là 1 loại lỗi, nhưng lỗi này NẰM TRONG PG → dễ phát hiện, dễ sửa

Verify bài toán 1:

PG tự kiểm PG — giống verify_counts(): 2 phương pháp độc lập, cùng nguồn, phải ra cùng kết quả
Ví dụ: meta_catalog liệt kê 15 loại → SELECT COUNT(DISTINCT collection) FROM birth_registry cũng phải ra 15
Ví dụ: verify_counts() so sánh trigger-based count vs SELECT COUNT(*) → 0 MISMATCH

Độ tin cậy: CAO — vì PG kiểm PG, không qua trung gian, không phụ thuộc UI/API/cache.

Tiền lệ thành công: birth_registry, meta_catalog, verify_counts(), species taxonomy — tất cả đều dùng phương pháp này và ĐÁNG TIN CẬY.

BÀI TOÁN 2: NUXT CÓ KHỚP SSOT KHÔNG?

Mục tiêu: Khi SSOT đã đúng (bài toán 1 đảm bảo), chỉ cần so sánh SSOT vs Nuxt.

Cơ chế:

SSOT nói có 30 danh mục → Nuxt hiện bao nhiêu? Thiếu = lỗi. Thừa = lỗi.
SSOT đếm 100 records → Nuxt hiện 90 → sai 10, biết chính xác sai ở đâu
SSOT liệt kê entity X tồn tại → Nuxt không hiện → mất entity

Verify bài toán 2:

2 nguồn (SSOT PG + Nuxt API/UI), so sánh trực tiếp
Bất kỳ ai chạy query PG + mở Nuxt → phải ra cùng kết luận
Evidence: PG=[giá trị cụ thể], Nuxt=[giá trị cụ thể], Delta=[sai lệch cụ thể]

Độ tin cậy: CAO — vì SSOT đã đúng (bài toán 1), chỉ cần so 2 con số.

KẾT HỢP 2 BÀI TOÁN

BÀI TOÁN 1: PG SSOT đúng không?    → PG tự kiểm PG (verify_counts, meta_catalog checks)
                                       ↓ ĐÃ ĐÚNG
BÀI TOÁN 2: Nuxt khớp SSOT không?  → So PG vs Nuxt (2 nguồn, so trực tiếp)
                                       ↓ KHỚP hoặc LỆCH (biết chính xác delta)
KẾT QUẢ: Hệ thống đáng tin cậy     → Mỗi bài toán đơn giản, tự chứng minh được

Đây chính xác là cách verify_counts() thành công: không phải vì code giỏi, mà vì phương pháp đúng — 2 bài toán đơn giản, mỗi bài tự chứng minh.

III. ÁP DỤNG — CONTRACT PHẢI TUÂN THỦ

Mọi contract check PHẢI thuộc 1 trong 2 bài toán:

Loại A — PG kiểm PG (Bài toán 1):

Chân lý: PG query 1
So sánh: PG query 2 (phương pháp khác, cùng nguồn)
Kỳ vọng: Query 1 = Query 2
Ví dụ: verify_counts(), meta_catalog coverage, species count

Loại B — PG vs Nuxt (Bài toán 2):

Chân lý: PG query (SSOT)
So sánh: Nuxt API hoặc UI
Kỳ vọng: PG = Nuxt
Evidence: PG=[X], Nuxt=[Y], Delta=[X-Y]
Ví dụ: registries count, entity hiển thị, species trên UI

Contract KHÔNG HỢP LỆ (phải loại bỏ):

Check UI element cụ thể (data-testid) mà KHÔNG dẫn nguồn từ PG
Check "kỳ vọng viết tay" không có SSOT backing
Check frontend design (bố cục, CSS, vị trí element)
Bất kỳ check nào mà KHÔNG THỂ chỉ ra "chân lý từ PG là gì"

IV. SSOT TỰ MỞ RỘNG — CHỐNG LỖI "QUÊN CẬP NHẬT"

Anh Huyên nhấn mạnh: web phát triển → thêm số mới, tính năng mới → SSOT phải tự mở rộng theo. Nếu SSOT không mở → đó cũng là lỗi.

Cơ chế:

meta_catalog = SSOT cho danh mục collections → Thêm collection mới → meta_catalog phải có → nếu thiếu = PG trigger/check tự phát hiện
birth_registry = SSOT cho entities → Thêm entity → birth_registry phải có → nếu thiếu = orphan detection phát hiện
Runner contract list = SSOT cho "cần kiểm tra gì" → Thêm trang mới → contract list phải mở rộng → nếu thiếu = coverage metric giảm → tự cảnh báo

Nguyên tắc: SSOT sai (thiếu, thừa, lỗi thời) cũng là 1 loại lỗi. Nhưng vì SSOT nằm trong PG → phát hiện lỗi SSOT dễ hơn, đáng tin cậy hơn phát hiện lỗi UI.

V. RÀ SOÁT DẦN (LOOP TIN CẬY)

Phase 1: Bài toán 1 — PG tự kiểm PG → xác nhận SSOT đúng
Phase 2: Bài toán 2 — Runner so PG vs Nuxt → tạo issues có evidence
Phase 3: Người/AI verify 5-10 issues bằng tay → confirm runner đúng/sai
Phase 4: Nếu runner sai → sửa contract/runner (hệ thống phát hiện nhầm)
Phase 5: Nếu mắt thấy lỗi runner không thấy → thêm contract (hệ thống thiếu)
Phase 6: Lặp lại cho đến khi Runner ≈ Mắt người

2 khả năng khi rà soát:

Hệ thống phát hiện nhầm → biết hệ thống có lỗi để sửa
Hệ thống không phát hiện hết → thêm contract để mở rộng coverage

Cả 2 đều tốt — loop nào cũng làm hệ thống tốt hơn.

VI. THAM CHIẾU

Bài học đếm: S111-S127, verify_counts() = 0 MISMATCH, birth_registry
"Cầu Chúa" = không có phương pháp chứng minh đúng (Huyên S132)
"Thước cong đo thẳng" = contract sai thì phát hiện cũng sai
"Giám sát máy bay" = WATCHDOG hỏng mà không ai biết (Huyên S132)
"Kẻ thù của sự chính xác" = tư duy rắc rối (Huyên S132)
"2 bài toán đơn giản" = chia phức tạp thành đơn giản, mỗi bài tự chứng minh (Huyên S132)