CÔNG THỨC THIẾT KẾ KHẢ THI — Design Feasibility Formula v1.0

(Bổ sung Hiến pháp Kiến trúc — Framework đánh giá mọi đề xuất thiết kế)

v1.0 | 2026-03-21 | S157 | Huyên đề xuất + Claude ghi nhận Áp dụng: MỌI đề xuất thiết kế, MỌI mission, MỌI architecture decision PHẢI pass 4 yếu tố.

---

NGUYÊN TẮC VÀNG

Thiết kế hệ thống để CHẠY. Khi đã chạy, KHÔNG SỬA CODE. Mỗi thay đổi kinh doanh → sửa code = thiết kế tồi, có vấn đề về tư duy. Thay đổi = thay đổi metadata/config/data. Code = bất biến.

---

4 YẾU TỐ KHẢ THI

Mọi đề xuất PHẢI trả lời đủ 4 câu hỏi. Thiếu 1 = KHÔNG KHẢ THI → dừng, bổ sung trước khi làm.

1. MÔ HÌNH TỔNG THỂ KHẢ THI

"Bức tranh lớn hoạt động thế nào?"

• Hệ thống hoạt động ra sao khi đã chạy?
• Khi có thay đổi (loài mới, entity type mới, business rule mới) → hệ thống tự thích ứng hay phải sửa code?
• Mô hình có chứa contradiction nội tại không?
• Mô hình có scale cho 99.5% tương lai chưa biết không?

Test: Mô tả hệ thống cho người không hiểu kỹ thuật trong 3 câu. Nếu không được = mô hình chưa rõ.

2. QUY TRÌNH THỰC HIỆN KHẢ THI, KHÉP KÍN

"Ai làm gì, bước nào, vòng lặp nào?"

• Quy trình có đầu vào + đầu ra rõ ràng?
• Quy trình có khép kín (output bước cuối → input bước đầu → vòng lặp)?
• Mỗi bước có trigger rõ ràng (event nào kích hoạt)?
• Không có bước nào phụ thuộc con người nhớ (phải tự động hoặc có alert)?
• Failure ở bất kỳ bước nào → có recovery path?

Test: Vẽ flowchart. Nếu có mũi tên đi vào void = quy trình chưa khép kín.

3. CÔNG CỤ ĐẦY ĐỦ

"Mỗi bước trong quy trình có tool thực hiện không?"

• Mỗi bước → DOT tool, PG trigger/function, Directus feature, hoặc script cụ thể?
• Tool đã tồn tại hay cần tạo mới?
• Nếu cần tạo → đó là prerequisite, phải làm TRƯỚC
• Tool có idempotent không (chạy lại không hỏng)?
• Tool có self-report không (ghi log, ghi kết quả)?

Test: Liệt kê tool cho mỗi bước. Nếu có bước = "manually" hoặc "TODO" = chưa đủ.

4. MÔI TRƯỜNG THỰC THI

"Các công cụ làm việc Ở ĐÂU?"

• Có collection/table/workspace cho tools hoạt động?
• Data cần thiết có sẵn trong môi trường?
• Permissions đủ?
• Performance acceptable (index, query plan)?

Ví dụ:

• Birth Registry → inspectors làm việc TRÊN birth_registry collection
• Species mapping → DOT tools làm việc TRÊN species_collection_map
• Label assignment → triggers làm việc TRÊN entity_labels
• Counting → queries chạy TRÊN birth_registry (không cần dynamic cross-table)

Test: Mỗi tool trong yếu tố 3 → chỉ ra nơi nó đọc/ghi. Nếu nơi đó chưa tồn tại = cần tạo trước.

---

CHECKLIST ÁP DỤNG

Trước mỗi đề xuất, Orchestrator PHẢI điền bảng:

## 4 YẾU TỐ KHẢ THI — [Tên đề xuất]

| # | Yếu tố | Mô tả | ✅/❌ |
|---|--------|-------|------|
| 1 | Mô hình tổng thể | [3 câu mô tả] | |
| 2 | Quy trình khép kín | [flowchart hoặc bước 1→2→3→...→1] | |
| 3 | Công cụ đầy đủ | [tool cho mỗi bước] | |
| 4 | Môi trường thực thi | [collection/table cho mỗi tool] | |

Thiếu yếu tố nào → BỔ SUNG TRƯỚC → rồi mới đề xuất.

---

VÍ DỤ ÁP DỤNG: BIRTH REGISTRY

#	Yếu tố	Mô tả	✅/❌
1	Mô hình	Entity sinh ra → tự có birth record → inspectors kiểm tra → certified. Thêm loài/inspector = thêm metadata, không sửa code.	✅
2	Quy trình	INSERT → trigger → birth record → inspect_pen → inspect_stamp → inspect_gate → auto certify. Fail → audit queue → fix → re-inspect. Khép kín.	✅
3	Công cụ	PG trigger (auto birth), dot-inspect-pen, dot-inspect-stamp, dot-inspect-gate, dot-certify-scan, dot-birth-orphan-scan	⚠️ Cần tạo
4	Môi trường	birth_registry collection = nơi inspectors đọc/ghi. Index trên certified=false.	✅

---

PHẢN VÍ DỤ: UNION ALL HARDCODE (cách cũ)

#	Yếu tố	Mô tả	✅/❌
1	Mô hình	Đếm = UNION ALL 16 tables. Thêm table = sửa VIEW.	❌ Phải sửa code
2	Quy trình	Thêm entity type → sửa VIEW → deploy → verify. Manual, không khép kín.	❌
3	Công cụ	Không có tool tự sửa VIEW. Manual.	❌
4	Môi trường	PG VIEW = code, không phải data.	❌

Kết luận: UNION ALL hardcode FAIL 4/4. Không khả thi cho tương lai.

---

v1.0 | S157 | Huyên đề xuất framework + Claude formal hóa "Muốn khả thi: mô hình + quy trình + công cụ + môi trường. Thiếu 1 = dừng."