Kiểm kê hệ thống + Cache + Nguyên tắc KHÔNG mất tính năng (vòng 13)

Date: 2026-06-20 | Trang chuẩn: https://vps.incomexsaigoncorp.vn/ui-preview/mcp-writes/he-thong-thiet-ke.html

Huyên lo: cache + tính năng bị mất qua nhiều lần

• Vẫn thấy thông tin cũ → cache.
• Sợ "làm việc nọ mất việc kia" (vd MOT: xác nhận · hoàn thành · danh sách đã hoàn thành).

Chẩn đoán (verified browser, mở mới)

MOT dashboard mở mới còn đủ: công tắc kho Công việc/Hoàn thành (storeSwitch ✓), nút Hoàn thành (.done-btn ✓), 6 việc, thẻ task, hướng dẫn trong thẻ, không lỗi JS. Nút xác nhận chỉ hiện ở việc có ô xác nhận (việc dùng form nhúng thì không có — không phải mất). ⇒ Tính năng KHÔNG mất; cái thấy cũ = tab cache.

CACHE — phân biệt rõ

• Thành phần chung (eco-nav) = tự đồng bộ (fetch lại + self-heal). OK.
• Nội dung từng trang = trình duyệt cache; PHẢI tải lại trang mới thấy bản mới (Ctrl/Cmd+Shift+R). Đây là hành vi cache tĩnh — không sửa được client-side cho body trang (cần header no-cache phía server VPS, ngoài tầm Cowork). Đã ghi cảnh báo này trên trang Thiết kế hệ thống.

NGUYÊN TẮC chống mất tính năng (enforce)

1. Kiểm kê chuẩn 1 chỗ: trang he-thong-thiet-ke.html liệt kê MỌI trang + tính năng → nhìn toàn cảnh, không gì biến mất âm thầm. Thêm/bớt trang phải cập nhật đây.
2. Không overwrite mà mất: mỗi trang là nguồn tính năng của nó; khi sửa phải GIỮ nguyên phần cũ. Core MOT (mot-dashboard/data/render/app/theme) KHÔNG bị Cowork sửa — chỉ append script → tính năng nguyên vẹn.
3. Verify sau mỗi thay đổi bằng trình duyệt (đã làm xuyên suốt).
4. Thành phần dùng chung (eco-nav/guide/master-list/guide-dock) = 1 nguồn, sửa 1 chỗ.

BẢN ĐỒ BẢNG PG (chốt schema — đã đưa lên trang)

Bảng	trạng thái	cột chính
field_registry	có	code·collection_code·name·field_kind·data_type·interface·validation·is_required·owner_mother·status
input_form_registry	có	code·target_collection·field_set·form_schema·routing·record_binding·guidance·status
output_table_registry	DỰNG	code·columns·data_fn·condition_ref·period·schedule·cron·triggers[]·recipients[]·export[]·guidance·status
trigger_registry	có	code·type·definition·status (thiếu→DOT tạo trước)
condition_registry	DỰNG	code·description_text·filter_code·params·status
workflow_registry	—	node·tier·parent·executors[]·recipients[]·store_collections[]·when·guidance·status
task_registry	—	code·input_form_ref·report_fields[]·triggers[]·when·executors[]·recipients[]·guidance·status
collection_registry + data	có	khoá bản ghi + cột nghiệp vụ
HR	—	id·name·dept·role
birth/governance	có	Đ0-G tạo-trước
guidance	jsonb	{text·diagram·audio·video·steps} (tách bảng nếu tái dùng)

LUỒNG LƯU (đếm bước ghi)

• VÀO direct: 1 ghi (→target_collection). VÀO queue: 2 ghi (staging→duyệt→target).
• RA: 0 ghi nghiệp vụ (chỉ đọc) + 1 lưu bản đúc/log + sự kiện phân phối.
• Design-time: mỗi khuôn = 1 ghi registry + 1 birth_registry.
• DOT: write input · run data_fn · apply condition · fire trigger · tạo-trước khi thiếu. PG-first, Nuxt render.

Việc tiếp (giữ "1 việc/lần")

1. Dựng UI khối Bản ghi (record_binding) + Điều kiện 2 ô (lời/mã) trong MODIT → MODUT.
2. Cơ chế "DOT tạo trước" ở picker (trigger/field/condition).
3. Khoá DDL output_table_registry + condition_registry.

2 bảng cần dựng mới: output_table_registry, condition_registry. Còn lại đã có hoặc nội bộ.