Incomex AI Portal
KB-30B2

Điều 31 — Bổ sung §III-B Phương Pháp Luận (S132)

5 min read Revision 1
dieu31amendmentmethodologyS132nguyên-tắc-72-bài-toán

Điều 31 — BỔ SUNG §III-B: PHƯƠNG PHÁP LUẬN CHỨNG MINH (S132)

Ngày bổ sung: 2026-03-24 | Session: S132 Tác giả: Anh Huyên (phương pháp), Claude Desktop (soạn thảo) Vị trí trong Luật: Sau §III Nguyên tắc 6, trước §IV Mô hình tổng thể Chi tiết đầy đủ: search_knowledge("dieu31 methodology 2 bài toán")

Nguyên tắc 7: CHIA BÀI TOÁN PHỨC TẠP → 2 BÀI TOÁN ĐƠN GIẢN (★ NỀN TẢNG)

"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

"Nếu không trả lời được 'Điều gì đảm bảo nó đúng?' — kết quả = cầu Chúa." — Huyên, S132

Bài học từ việc đếm

Đếm = việc tĩnh, đơn giản nhất. 4 tầng code đếm sai mấy tuần liền. Phát hiện lỗi (Điều 31) = việc ĐỘNG, phức tạp hơn đếm. Nếu phương pháp không chuẩn → vòng luẩn quẩn y hệt.

Giải pháp đếm thành công: PG ID = chân lý, verify_counts() = 2 phương pháp độc lập cùng nguồn → phải ra cùng kết quả. Phương pháp đúng quan trọng hơn code giỏi.

Không giải trực tiếp bài toán phức tạp

"Web có đúng không?" = bài toán phức tạp, KHÔNG giải trực tiếp được.

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?

Nguyên lý: PG là nguồn chân lý gốc. SSOT phải tự đảm bảo đúng bằng PG tự kiểm PG.

Cơ chế:

  • Muốn đếm/giám sát cái gì → TẠO collection PG tự ghi tổng biến động
  • Thêm tính năng/số mới trên web → Collection PG TỰ MỞ RỘNG THEO
  • Collection KHÔNG mở rộng theo = 1 loại lỗi, nhưng nằm trong PG → dễ phát hiện

Verify: PG tự kiểm PG — verify_counts(), meta_catalog check, species count cross-check. 2 phương pháp độc lập, cùng nguồn, phải ra cùng kết quả.

Độ tin cậy: CAO — không qua trung gian.

Tiền lệ: birth_registry, meta_catalog, verify_counts(), species taxonomy.

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

Nguyên lý: Khi SSOT đã đúng (bài toán 1), chỉ cần so SSOT vs Nuxt.

Cơ chế:

  • SSOT 30 danh mục → Nuxt hiện bao nhiêu? Thiếu = lỗi. Thừa = lỗi.
  • SSOT đếm 100 → Nuxt hiện 90 → sai 10, biết chính xác delta.

Verify: 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 bắt buộc: PG=[giá trị], Nuxt=[giá trị], Delta=[sai lệch].

Độ tin cậy: CAO — SSOT đã đúng, chỉ so 2 số.

KẾT HỢP

BÀI TOÁN 1: PG SSOT đúng?     → PG tự kiểm PG    → ĐÃ ĐÚNG
BÀI TOÁN 2: Nuxt khớp SSOT?   → So PG vs Nuxt     → KHỚP/LỆCH (delta cụ thể)
KẾT QUẢ: Mỗi bài đơn giản, tự chứng minh → Toàn bộ hệ thống đáng tin cậy

§III-B.2 SSOT TỰ MỞ RỘNG — LUẬT BẮT BUỘC

Web phát triển (thêm collection, tính năng, số liệu) → SSOT trong PG PHẢI tự mở rộng theo. Nếu SSOT không mở rộng → hệ thống giám sát bị "mù" với phần mới → đây cũng là 1 loại lỗi.

3 cơ chế tự mở rộng:

  1. meta_catalog = SSOT cho collections → thêm collection → meta_catalog phải tự có
  2. birth_registry = SSOT cho entities → thêm entity → birth_registry phải tự có
  3. Runner contract list = SSOT cho "cần kiểm tra gì" → thêm trang → coverage giảm → tự cảnh báo

Lỗi SSOT cũng là lỗi — nhưng vì nằm trong PG → phát hiện dễ hơn, đáng tin cậy hơn phát hiện lỗi UI.

§III-B.3 CONTRACT PHẢI TUÂN THỦ

Mọi contract check PHẢI thuộc 1 trong 2 loại:

Loại Bài toán Chân lý So sánh Ví dụ
A PG kiểm PG PG query 1 PG query 2 (phương pháp khác) verify_counts, meta_catalog check
B PG vs Nuxt PG SSOT Nuxt API/UI registries count, entity hiển thị

Contract KHÔNG HỢP LỆ (PHẢI loại bỏ):

  • Check data-testid UI mà không dẫn nguồn từ PG
  • Check "kỳ vọng viết tay" không có SSOT backing
  • Check frontend design (CSS, layout, vị trí)
  • Bất kỳ check nào không chỉ ra được "chân lý từ PG là gì"

§III-B.4 RÀ SOÁT DẦN — LOOP TIN CẬY

2 khả năng khi rà soát (cả 2 đều tốt):

  1. Hệ thống phát hiện nhầm → biết runner/contract có lỗi → sửa
  2. Mắt thấy lỗi runner không thấy → thêm contract → mở rộng coverage

Loop:

Phase 1: PG tự kiểm PG → xác nhận SSOT đúng
Phase 2: Runner so PG vs Nuxt → tạo issues có evidence
Phase 3: Người/AI verify 5-10 issues → confirm runner đúng/sai
Phase 4: Sửa runner/contract nếu sai HOẶC thêm contract nếu thiếu
Phase 5: Lặp lại cho đến khi Runner ≈ Mắt người

Phụ lục §III-B, Điều 31 v1.3. Bổ sung S132. SSOT chi tiết: knowledge/dev/architecture/dieu31-methodology.md