KB-4D2A
S148 Council Prompt — Rà soát Hiến pháp v4.0
8 min read Revision 1
councilprompts148constitutionv4.0reviewgptgemini
PROMPT HỘI ĐỒNG — RÀ SOÁT HIẾN PHÁP v4.0
Dùng cho: GPT (ChatGPT) và Gemini Ngày: 2026-03-30 | Phiên S148 Báo cáo lập tại:
https://vps.incomexsaigoncorp.vn/knowledge/current-state/reports/
BỐI CẢNH
Hệ thống Incomex Saigon Corp đã trải qua nhiều tháng xây dựng kiến trúc. Trong quá trình đó, các agents (AI) liên tục mắc sai lầm thiết kế ngơ ngẩn — ALTER TABLE trực tiếp bypass Directus, hardcode columns trong Nuxt, fix triệu chứng thay vì fix gốc, thiếu trigger phụ khiến hệ thống chạy mà không ai biết có đang đúng không, và nhiều vấn đề khác.
Hệ quả: Owner (Huyên) quyết định nâng cấp Hiến pháp Kiến trúc từ v3.9 → v4.0 với những thay đổi lớn:
- Tuyên ngôn Thiết kế mới: "Giải quyết vấn đề ≠ giải quyết vấn đề VĨNH VIỄN." Ba hệ quả: muốn nhầm cũng không thể, DOT kiểm tra = nhiệt kế không phải thuốc, không fix vụ việc chỉ fix gốc.
- 9 Nguyên tắc Nền tảng (mở rộng từ 5 Luật Bất biến cũ): thêm "5 tầng đồng bộ — cấm code Nuxt", "Dual-trigger", "Assembly First — code là giải pháp cuối", "Không chắc đúng = Sai".
- Cấu trúc lại: Tách 1 file hiến pháp 75K chars → hiến pháp ngắn gọn + 18 file luật chi tiết trong folder
laws/. - Chốt hạ tầng: PostgreSQL 16 DUY NHẤT (MySQL RETIRED vĩnh viễn), Chatwoot (CSKH), Lark Suite Enterprise (nội bộ + Base kết nối PG), i18n 3 ngôn ngữ (vi/ja/en), multi-domain kiến trúc.
TÀI LIỆU CẦN ĐỌC
Tài liệu MỚI (v4.0) — vị trí: https://vps.incomexsaigoncorp.vn/knowledge/dev/laws/
Đọc theo thứ tự ưu tiên:
| # | File | Nội dung | Ưu tiên |
|---|---|---|---|
| 1 | constitution.md |
Hiến pháp v4.0 — Tuyên ngôn + 9 Nguyên tắc + Chuỗi lắp ráp + 2 Động cơ + Mục lục luật + Hạ tầng chốt | 🔴 ĐỌC TRƯỚC |
| 2 | law-01-foundation-principles.md |
9 Nguyên tắc Nền tảng — chi tiết | 🔴 |
| 3 | law-00h-5layer-sync.md |
Điều 0-H: 5 tầng đồng bộ, DOT 2 cấp, 2 động cơ | 🔴 |
| 4 | existing-law-references.md |
Tham chiếu luật đã có file riêng + ⚠️ cảnh báo DFL v1.1 lỗi thời | 🔴 |
| 5 | law-02-registry.md |
Điều 2: Prefix Active + Planned + Kế hoạch | 🟡 |
| 6 | law-03-metadata.md |
Điều 3: Khung metadata bắt buộc + mở rộng | 🟡 |
| 7 | law-05-five-tiers.md |
Điều 5: 5 Tầng kiến trúc + hiện trạng | 🟡 |
| 8 | law-07-assembly-first.md |
Điều 7: Assembly First + hoà giải Điều 0-H | 🟡 |
| 9 | law-10-13-operations.md |
Điều 10-13: Inject, Idempotent, Vòng đời, Danh mục Sống | 🟡 |
| 10 | law-15-16-state-checkpoint.md |
Điều 15-16: State Machine + Checkpoint schema chi tiết | 🟡 |
| 11 | law-17-18-domain-change.md |
Điều 17-18: Multi-domain, i18n, Chatwoot, Lark, 15 loại thay đổi | 🟡 |
| 12 | law-19-orphan-scanner.md |
Điều 19: Orphan Scanner Side B | 🟡 |
| 13 | law-22-self-healing.md |
Điều 22: Self-Healing + 3 danh mục + 7 DOT Tầng 5 | 🟡 |
| 14 | roadmap.md |
Lộ trình 5 Phases — status + backlog + TD mới | 🟡 |
| 15-18 | law-04, law-06, law-08, law-09 |
Các luật ngắn đã có | 🟢 |
Tài liệu CŨ (v3.9) — vị trí: https://vps.incomexsaigoncorp.vn/knowledge/dev/architecture/
| File | Nội dung | Vai trò |
|---|---|---|
index.md |
Hiến pháp CŨ v3.9 — 75K chars, 34 Điều. Đây là nguồn tinh hoa cần kiểm tra không bị rơi rụng. | SO SÁNH |
information-atom-law.md |
Điều 0 chi tiết: Nguyên tử Thông tin, 5 điều kiện, phép so sánh vật lý | Tham khảo |
composition-level-law.md |
Điều 0-B chi tiết: 7 lớp cấu tạo, 33 species | Tham khảo |
birth-registry-law.md |
Điều 0-G chi tiết: Birth Registry | Tham khảo |
label-law.md |
Điều 24 chi tiết: 6×6 Faceted Classification (ĐÓNG BĂNG) | Tham khảo |
system-integrity-law.md |
Điều 31 chi tiết: Contracts, Runner, WATCHDOG | Tham khảo |
duplicate-prevention-law.md |
Điều 14 chi tiết: 3 cấp chống trùng | Tham khảo |
Tài liệu hỗ trợ — vị trí: https://vps.incomexsaigoncorp.vn/knowledge/dev/ssot/
| File | Nội dung |
|---|---|
data-connection-law.md |
⚠️ Luật Luồng DL v1.1 — LỖI THỜI 80%+. Ghi MySQL, Firestore, GCS, Lark, Cloud Run — tất cả đã RETIRED. Đọc để biết cần viết lại cái gì. |
operating-rules.md |
Nguyên tắc vận hành hàng ngày |
anti-patterns.md |
16 bài học từ incidents |
YÊU CẦU
Đọc kỹ TẤT CẢ tài liệu MỚI (laws/) và CŨ (architecture/index.md). Sau đó trả lời 3 câu hỏi dưới đây.
Câu 1: RƠI RỤNG — Tài liệu cũ (v3.9) có nội dung quý nào bị rơi rụng trong tài liệu mới (v4.0)?
Tinh hoa cũ (index.md 75K chars) được xây bằng nhiều tháng công sức + tiền bạc. Đặc biệt kiểm tra:
- Điều 0: 5 điều kiện nguyên tử, luật bảo toàn (ID không tái sử dụng, quan hệ không tự mất, metadata không giảm)
- Điều 0-B: 7 lớp cấu tạo (hạ nguyên tử đến công trình) — phải là 7, không phải 6
- Điều 2: Prefix planned (TP, CPI, SCR, API, CMP, JT, EVT, DOM)
- Điều 3: 13 fields metadata (8 bắt buộc + 5 tuỳ chọn)
- Điều 13: Bảng mô hình A/B (11 loại thực thể), meta-catalog schema (10 fields)
- Điều 14: Engine chống double 3 cấp (exact/semantic/structural)
- Điều 15-16: Schema chi tiết (step_type, workflow_mode, 3 bảng checkpoint, journey templates)
- Điều 17: Schema
domains(18 fields), i18n 3 ngôn ngữ - Điều 18: Bảng 15+ loại thay đổi cần workflow
- Điều 22: Ba danh mục song song, bảng DOT Tầng 5 phạm vi phủ sóng
- Roadmap 5 Phases (checklist chi tiết Phase 0-5)
- Các kết luận hội đồng review trước đó (Gemini + GPT + Claude Code)
Format trả lời:
| Điều | Nội dung bị rơi (nếu có) | Ở đâu trong CŨ | Đề xuất |
Câu 2: XUNG ĐỘT — Tài liệu mới có xung đột NỘI BỘ hoặc xung đột với KỸ THUẬT không?
Đặc biệt kiểm tra:
- Điều 0-H "CẤM ALTER TABLE" vs Điều 7 "PG trước nhất" — đã hoà giải, kiểm tra hoà giải có đủ rõ?
- Điều 0-H "DOT Cấp B secret" vs Điều 9 "SCR → Council → DOT" — chuỗi quy trình rõ chưa?
- Nguyên tắc 6 "5 tầng đồng bộ" vs Điều 0-H (luật chi tiết) — trùng hay bổ sung?
- Nguyên tắc 8 "Assembly First" vs Điều 7 — trùng hay bổ sung?
- Nguyên tắc 7 "Dual-trigger" — có khả thi kỹ thuật cho MỌI thực thể nhận trigger?
- DFL v1.1 ghi MySQL/Firestore/GCS — thực tế chỉ PG + Directus + VPS → xung đột nghiêm trọng?
- Lark Base ↔ PG sync — PG FDW/LISTEN/NOTIFY đủ hay cần thêm middleware?
- Chatwoot → Agent Data webhook — verify HMAC có đúng cơ chế?
Format trả lời:
| Luật A | Luật B | Xung đột | Mức | Đề xuất giải quyết |
Câu 3: GÓP Ý — Có gì cần bổ sung, hiệu chỉnh, tối ưu?
Góp ý tự do. Ví dụ:
- Có nguyên tắc nào THIẾU mà nên thêm?
- Có luật nào quá dài/phức tạp mà nên chia nhỏ?
- Cấu trúc laws/ folder có hợp lý?
- Thuật ngữ có nhất quán? (Lớp vs Tầng vs Layer)
- 9 nguyên tắc có đủ mạnh? Có chỗ nào agent vẫn có thể "lách"?
- Tuyên ngôn Thiết kế có rõ ràng, dễ hiểu cho agent mới?
- Kiến trúc PG + Lark Enterprise (không cần n8n) — có rủi ro gì?
BÁO CÁO
Lập báo cáo theo format:
GPT: https://vps.incomexsaigoncorp.vn/knowledge/current-state/reports/s148-council-gpt-constitution-v4-review
Gemini: https://vps.incomexsaigoncorp.vn/knowledge/current-state/reports/s148-council-gemini-constitution-v4-review
Cấu trúc báo cáo:
# S148 Council Review — Hiến pháp v4.0
**Agent:** [GPT/Gemini]
**Ngày:** 2026-03-30
## Câu 1: Rơi rụng
[bảng kết quả]
## Câu 2: Xung đột
[bảng kết quả]
## Câu 3: Góp ý
[danh sách góp ý]
## Tổng kết
[1-3 câu tóm tắt đánh giá]
LƯU Ý QUAN TRỌNG
- Đọc CẢ CŨ VÀ MỚI. Không chỉ đọc mới rồi nói "OK". Mục đích chính là so sánh.
- Trung thực. Nếu thấy vấn đề — nói rõ. Nếu không thấy — nói "không tìm thấy rơi rụng/xung đột".
- Cụ thể. Trích dẫn Điều nào, file nào, dòng nào. Không nói chung chung.
- Assembly First áp dụng cho review: Dùng search_knowledge để đọc. Đọc file gốc, không đoán.
S148 | Council Review | Hiến pháp v4.0 | GPT + Gemini