ĐIỀU 41 — PHỤ LỤC KẾ HOẠCH TRIỂN KHAI

Loại: Living document (cập nhật liên tục khi điều tra thêm)
Tạo: 2026-04-14 (S176B sau khi Đ41 v1.0 BAN HÀNH)
Mục đích: Tập hợp mọi thứ Đ41 cần khi triển khai Phase 1 — cái gì đã có, cái gì chưa, blocker là gì, ai/lệnh nào đã verify. Mỗi điều tra mới → cập nhật bảng. Không khai gì mới ngoài bảng này.

§1. BẢNG TỔNG ARTIFACT CẦN CHO PHASE 1

#	Artifact	Loại	Đã có?	Verify (cmd/source)	Blocker	Ghi chú
A1	`vps_deploy_log`	PG collection (Directus)	❌	`directus_collections WHERE collection ILIKE '%deploy%'` = 0 rows (CLI 2026-04-14)	Cần tạo qua Directus Collections API + DOT Cấp B (Đ0-H)	Schema 15 cột định ở Đ41 §8
A2	`smoke_profiles`	PG collection (Directus)	❌	Cùng query A1 = 0 rows	Cần tạo qua Directus API	Mỗi app = 1 row (nuxt, directus, agent-data)
A3	`infra_artifacts` (đề xuất tên)	PG collection (Directus)	❌ GAP MỚI	`tables WHERE name ILIKE '%infra%/%script%/%deploy%'` = 0 rows	Quyết định kiến trúc chờ chốt (xem §3-Q1)	Đăng ký script `.sh`, smoke profile mapping, nginx config, retention policy...
B1	Domain `infrastructure.deploy`	dot_domains row	✅	`dot_domains WHERE code='infrastructure.deploy'` = 1 row "Triển khai"	—	Sẵn cho 6 DOT Đ41
B2	Species `SPE-LOG` (Nhật ký Hệ thống)	entity_species row	✅	`entity_species WHERE code='SPE-LOG'` = 1 row	Linkage thực tế ↔ collection chưa xác định (xem §4-TD)	Dự kiến gán cho `vps_deploy_log`
B3	Species `SPE-GOV` (Hạ tầng Giám sát)	entity_species row	✅	Cùng query B2	Cùng B2	Dự kiến gán cho `smoke_profiles` + `infra_artifacts`
B4	Species `SPE-SYS` (Hệ thống/Backup)	entity_species row	✅	Cùng query B2	—	Dự phòng cho release retention
C1	DOT-COL-CREATE	DOT tier B	✅ row	`dot_tools WHERE code='DOT-COL-CREATE'` (CLI 2026-04-14)	file_path drift (S164c TD) + `last_executed=NULL`	Có thể là DOT tạo collection — phải đọc code để xác nhận behavior
C2	DOT-COL-HEALTH	DOT tier A	✅ row	Cùng query C1	Cùng C1	Pair của C1 và C3
C3	DOT-COL-SYNC	DOT tier B	✅ row	Cùng query C1	Cùng C1	Có thể dùng cho field sync sau khi tạo collection
C4	DOT-SPECIES-MAP (gán species cho collection)	DOT	❌ THIẾU	`dot_tools WHERE code ILIKE '%species-map%'` = 0 rows	Không có DOT chuyên trách. Có thể C1 đã cover — phải verify qua code	QT-003 bước 3 yêu cầu
C5	DOT-BIRTH-TRIGGER-SETUP	DOT	❌ THIẾU	`dot_tools WHERE code ILIKE '%birth-trigger-setup%'` = 0 rows	Không có DOT chuyên trách	QT-003 bước 4 yêu cầu
D1	dot-vps-deploy-guard	DOT mới (tier A)	❌ slate sạch	`dot_tools` query Q5 (CLI) = 0 rows	Tạo theo Đ35 §5 8 bước	domain `infrastructure.deploy`, op `health`, cron
D2	dot-vps-deploy-audit	DOT mới (tier A)	❌	Cùng Q5	Cùng D1	Pair với D4 (release-cleanup)
D3	dot-infra-config-guard	DOT mới (tier A)	❌	Cùng Q5	Cùng D1	domain `infrastructure`, op `health`
D4	dot-vps-release-cleanup	DOT mới (tier B)	❌	Cùng Q5	Cùng D1 + cần `paired_dot=D2`	Xoá release cũ (retention 5+24h)
D5	dot-vps-deploy-watch	DOT mới (tier A)	❌	Cùng Q5	Cùng D1	trigger `on-demand` (gọi sau swap)
D6	dot-env-drift-check	DOT mới (tier A)	❌	Cùng Q5	Cùng D1	Hash compare `.env.production` SSOT vs release
E1	`app-deploy.sh` script	Infra utility	❌	`find /opt/incomex/deploy/` chưa probe	Phụ thuộc A3	Đăng ký vào `infra_artifacts` (A3)
E2	`infra-deploy.sh` script	Infra utility	❌	Chưa probe	Cùng E1	Cùng cách E1
F1	Thư mục `/opt/incomex/{app-dev,app-production,infra,deploy,secrets}`	Filesystem	❌	`ls /opt/incomex/` chưa probe	Hiện đang là `/opt/incomex/docker/...` — phải migrate	Đ41 §2 quy định layout mới
F2	Snapshot mã hiện tại → release legacy đầu tiên	Filesystem + sổ tay	❌	—	Phụ thuộc A1 (cần `vps_deploy_log` để ghi)	Đ41 §10 bước 2

Tổng hợp: 13/22 artifact ❌ chưa có. 4/22 ✅ hoàn toàn. 5/22 ⚠️ có row nhưng cần verify hành vi.

§1.1 — ★★★ CẬP NHẬT 2026-04-14 S177 Fix 8 (POST BAN HÀNH v5.1)

Bản chất blocker đã thay đổi LẦN 2 (Fix 7 chuyển sang TẦNG LUẬT, Fix 8 đã đóng):

Trước Fix 8 (Tầng luật)	Sau Fix 8 (v5.1 ban hành)
"Đ35 v5.0 có lỗ hổng 4 LAW GAP"	✅ v5.1 FINAL BAN HÀNH. 4 GAP + 7 minor fix R2 đã đóng trong `dieu35-dot-governance-law.md` rev 2
"Prompt S155 thiếu 5 bảng → 49 DOT POST-S151 vẫn 94% NULL"	⏳ Còn — phải chạy BLOCK 4 retrofit (T8 §13.5) để backfill 272 DOT
"fn_birth_gate mode=warning không chặn"	✅ Luật v5.1 §8.3 đã viết configurable. ⏳ Thực thi trên VPS: sau BLOCK 4 chạy PASS + 3 ngày H10-14 clean → `UPDATE birth_gate_mode='block'` (T14 §13.5)
"dot-dot-register thiếu 5 cột + flow INACTIVE"	⏳ T2 + T3 §13.5 — phải vá script + bật flow trên VPS
"Reference tables missing + dot_config missing"	⏳ T8 §13.5 BLOCK 1 bootstrap — phải chạy migration đầy đủ 7 bảng
"§retrofit clause thiếu"	✅ Luật v5.1 §11 có đầy đủ. ⏳ T11 §13.5 — audit chéo Đ36/37/38/39/41 xem luật nào đã ban hành cần amend thêm retrofit
"fn_log_issue curl silent-fail"	✅ Luật v5.1 §4.1B định nghĩa SQL wrapper. ⏳ T8 §13.5 BLOCK 3 — phải CREATE FUNCTION trên VPS

→ Pha hiện tại: TỪ "viết luật" chuyển sang "triển khai luật trên VPS" theo §13.5 14 TODO. Phụ lục này vẫn là living doc, cập nhật khi mỗi TODO đạt mốc.

§1.2 — LỊCH SỬ (cũ, giữ để audit)

§2. CÁI ĐÃ ĐIỀU TRA + BẰNG CHỨNG

Ngày	Việc	Kết quả	Bằng chứng
2026-04-14	CLI probe S176-DIEU41-PRE-BIRTH-PROBE Q1-Q5 (pattern hẹp)	Slate hầu như sạch, 3 DOT-COL-* có row, GAP infra_artifacts	Báo cáo CLI message 2026-04-14 (xem chat S176B)
2026-04-14	Desktop đọc 5 luật cốt lõi: HP v4.5.1, Đ0-H, Đ7, Đ29, Đ35, Đ36, QT-003 (`birth-procedures.md`)	Nắm quy trình khai sinh collection mới qua Directus API + DOT Cấp B + 6 bước QT-003	conversation S176B
2026-04-14 #3	⚠️ SAI LẦM ĐÃ PHÁT HIỆN (Huyên cảnh báo): Probe Q1 chỉ tìm bằng pattern tên hẹp (`%species-map%`, `%collection-register%`, `%birth-trigger-setup%`) → vội kết luận "thiếu DOT". Hệ thống có ~200 DOT, có thể đã có DOT cùng chức năng nhưng đặt tên khác (vd `DOT-CLASSIFY-`, `DOT-BIRTH-`, `DOT-NRM-`). Phải điều tra rộng theo `domain` + `operation` + `file_path` content TRƯỚC KHI kết luận thiếu.* Sai lầm gốc: pattern matching tên = không đủ.	Huyên S176B 2026-04-14
2026-04-14 #4	🔴 CRISIS — DOT COVERAGE AUDIT (S176-DIEU41-DOT-COVERAGE-AUDIT) — Tổng 272 DOT. 3 lớp registry song song cùng trỏ 3 file vật lý `dot-collection-{create,health,field-sync}`: (a) Lớp 1 `DOT-XXX` số coverage=partial, (b) Lớp 2 `DOT_UPPER_SNAKE` coverage=NULL paired=DOT-HEALTH-DOT, (c) Lớp 3 `DOT-COL-` descriptive coverage=complete paired=DOT-COL-HEALTH ext `.ts` SAI 100%. `operation=NULL` 94% (255/272), `coverage_status complete` chỉ 5% (13/272). birth_registry 100% rỗng-có-row* — macro OK nhưng depth FAIL. 3 DOT khai sinh QT-003 ĐỀU TỒN TẠI dưới Lớp 1+2 (DOT-119 birth-trigger-setup, DOT-120 collection-register, DOT-145 species-map). `dot-collection-create` v2.0.0 đã có Step 17 species mapping + Step 18 birth trigger native — không cần sub-DOT. S164b/c là sự kiện thật trên VPS (10+ .bak files) nhưng KHÔNG trace được trong git/KB — audit gap nghiêm trọng.	Báo cáo CLI S176B 2026-04-14
2026-04-14 #5	🔴 CẢNH SÁT NGỦ (suspect) — Lớp 3 có coverage=complete + file_path .ts sai 100%. Đ35 §8.1 H4 phải alert nhưng không thấy. 3 khả năng: (a) `dot-dot-health` chưa chạy bao giờ (last_executed=NULL), (b) có chạy nhưng path resolve mềm, (c) alert vào system_issues nhưng không ai đọc. Nếu cảnh sát chính ngủ → mọi metric coverage vô nghĩa. Pattern lặp "self-healing-late" S176 KS.2.	Suy ra từ #4
2026-04-14 #6	✅ ĐỌC LẠI Đ0-B + vector search về DOT-118/119/fn_birth_registry_auto — Sửa hiểu sai trước đó. Định nghĩa CHUẨN: (a) DOT = NGUYÊN TỬ Lớp 1 Đ0-B (`composition_level='atom'`), 1 DOT = 1 atom độc lập của loài DOT đã có sẵn — sinh DOT mới KHÔNG sinh loài mới. (b) QT-002 "khai trước sinh sau" áp dụng cho mọi instance mới của loài đã có, không giới hạn "loài mới". (c) DOT-119 setup birth trigger cho 133 collections dùng chung `fn_birth_registry_auto` — INSERT vào collection nào auto trigger row birth_registry. (d) DOT-118 backfill = QT-001 nhập birth_registry cho entity đã tồn tại, scope cấp collection. (e) 272/272 DOT đều có birth_registry row vì dot_tools là 1 trong 133 collection có trigger auto, KHÔNG phải nhờ backfill thủ công. Vấn đề thực sự không ở birth_registry (đã đầy đủ) mà ở `dot_tools` METADATA: operation 94% NULL, coverage 95% partial/NULL, 3 lớp convention trùng lặp, Lớp 3 phantom file_path .ts. "Khai lại" theo nghĩa Huyên = bổ sung metadata thiếu + retire 2 lớp trùng + fix phantom, không phải backfill birth_registry.	Vector search S176B 2026-04-14
2026-04-14 #7	⚠️ SAI LẦM ĐÃ PHÁT HIỆN (Huyên cảnh báo lần 2): (1) Em dùng từ "zombie" — sáng tác bậy, không có trong luật. Đúng từ phải là PHANTOM (Lớp 3 file_path drift) hoặc khai sinh chưa đầy đủ (metadata partial). (2) Em hiểu sai QT-002: nghĩ rằng "khai trước sinh sau" = entity loài mới. ĐÚNG là cho mọi cá thể mới của loài đã có. Bài học: Trước khi dùng thuật ngữ → search vector + đọc luật. KHÔNG sáng tác từ. KHÔNG hỏi user việc có thể tự điều tra.	Huyên S176B 2026-04-14
2026-04-14 #8	✅ Phase 0 G1-G4 audit CLI DONE — Cảnh sát `dot-dot-health` THỨC nhưng CÂM: cron daily 3AM chạy đều, log 278KB, phát hiện đúng (244 orphan + 60 NULL + 5 coverage gap) NHƯNG exit 0, 0 row escalate vào `system_issues`. 3 lớp convention: L1_NUMBER 163, L2_UPPER_SNAKE 100, L3_DESCRIPTIVE 4, OTHER 5. 45 cặp duplicate (L1↔L2 trỏ cùng basename, prefix path khác nhau nên string-equality miss). 13 coverage=complete: 7 NULL file_path + 6 phantom .ts 100% sai, 0/13 khớp file thật. S164b/c: 56 .bak file tạo trong 13 phút 2026-04-04 02:39-02:52 UTC, original 10/10 còn tồn tại (backup-only, không xoá).	CLI report S176B 2026-04-14
2026-04-14 #9	🔴 INSIGHT GỐC RỄ (Huyên) — "DOT ra đời trước, luật ra đời sau, bảng khai sinh ra đời sau → vênh khắp nơi." Timeline: DOT đầu có từ S109-, Đ0-G (birth registry) S147, Đ35 v5.0 (DOT governance) S151. Khoảng trống 5-6 tháng legacy. Đ35 v5.0 ban hành KHÔNG có `retrofit clause` → 272 DOT cũ mãi vênh luật. Lỗ hổng kiến trúc sâu: luật mới không kèm "operation khai sinh lại legacy" → pattern sẽ lặp với Đ36/38/39/41. Mục tiêu mới: tranh thủ lần này KHAI SINH TOÀN BỘ DOT (retrofit 272 legacy + register 244 mồ côi + fix 60 metadata shell + dedupe 45 pair + fix cảnh sát câm). Đ41 chỉ là use case trigger.	Huyên S176B 2026-04-14
2026-04-14 #10	✅ Big picture SỐ THẬT sau audit — `/opt/incomex/dot/bin/` có ~411 file vật lý (244 orphan + 167 unique basename đã đăng ký). Registry 272 row. 33% file thật không có sổ. Phân loại đúng theo từ chuẩn: (a) 244 MỒ CÔI (Đ19 Side B — file disk không row registry), (b) 60 PHANTOM metadata shell (row có, file_path=NULL), (c) 6 PHANTOM path drift (file_path .ts sai 100%), (d) 45 cặp DUPLICATE (trùng semantic qua 2 convention), (e) 259/272 KHAI SINH CHƯA ĐẦY ĐỦ (coverage partial/NULL, operation 94% NULL), (f) 1 CẢNH SÁT CÂM (dot-dot-health exit 0 không escalate).	Tổng hợp từ G1-G4
2026-04-14 #11	✅ CLI LAW GAP VERIFY S177 HOÀN TẤT — Claude Code trả lời 10 câu C1-C10 bằng evidence cứng trên VPS (báo cáo `reports/s177-dieu41-law-gap-verify-20260414.md` ~17KB). 4 root cause: RC-A engine `dot-dot-register` mù (set 6/10 fields khi register, hardcode `paired_dot=DOT-HEALTH-DOT`, emit Lớp 2 UPPER_SNAKE + flat domain không match dotted seed) → 94% NULL operation ngay từ register; RC-B `dot-dot-health` có code `log_system_issue` nhưng `curl \|\| true` silent-fail → cảnh sát có miệng mà nuốt; RC-C Bootstrap §9.2 BLOCK 1 chết — `dot_config` + 4 reference tables KHÔNG tồn tại trên VPS dù KB nói DONE; RC-D luật §4.1 nullable hợp pháp + §8.1 thiếu H10/H11 + §9.3 grace không enforce + §retrofit thiếu. 3 LG mới: LG-5 trigger duplicate `birth_trigger_dot_tools` × 2, LG-6 reference tables missing (BLOCK 1 dở dang), LG-7 vocabulary mismatch (engine flat domain + 12 op thực trong đó 8/12 ngoài luật seed).	Báo cáo CLI
2026-04-14 #12	🔴 PHÁT HIỆN GÂY SỐC NHẤT (C10): 49 DOT tạo SAU S151 (ngày ban hành Đ35 v5.0) vẫn 94% NULL operation. → Bệnh KHÔNG phải retrofit cho legacy mà engine không tuân luật ngay cả sau khi luật ban hành. Retrofit clause phải áp CHO CẢ DOT mới. Hệ quả suy rộng: Đ36 (S155 "DONE"), Đ38 (S164 "100% CLOSED"), Đ39 (S160 "enacted"), Đ41 (vừa ban hành) có khả năng cao cũng bị bệnh này → cần audit chéo sớm.	C10 raw
2026-04-14 #13	⚠️ MÂU THUẪN KB ↔ VPS RUNTIME (bệnh gốc sâu nhất) — KB vector search nói: "S155 bootstrap Đ35+Đ36 ĐÃ HOÀN THÀNH. PR #655 merged. 4 SSOT tables tạo xong. Đ35 chuyển sang active production với 4 lớp bảo vệ." VPS runtime psql: "dot_config + dot_tiers + dot_operations + dot_trigger_types + dot_coverage_statuses KHÔNG TỒN TẠI trong DB directus." → Pattern metadata-shell S176 KS.3 lặp ở TẦNG LUẬT. Mọi quyết định kiến trúc 1.5 tháng qua dựa trên giả định "Đ35 active" → có thể toàn bộ kiến trúc đang đứng trên nền xi măng giả. Đã soạn prompt CLI V2 (4 lệnh, §10 handoff S177) chờ Huyên duyệt để xác định: (1) tables tên khác, (2) bootstrap fail silent, hay (3) PR #655 chỉ merge code không kèm SQL.	Đối chiếu CLI C5 vs search_knowledge S155 handoff
2026-04-14 #14	✅ CLI V2 BOOTSTRAP VERIFY HOÀN TẤT — báo cáo `reports/s177-dieu41-bootstrap-verify-20260414.md`. Sự thật phơi bày: (a) `dot_domains` 39 rows + `dot_coverage_required` 11 rows EXIST — nhưng KHÔNG từ PR #655 (PR #655 = commit 75faf48 trong `/opt/incomex/docker/nuxt-repo`, 9 file bash, 2124 insertions, 0 SQL, 0 CREATE TABLE). (b) 5 bảng §9.2 (`dot_config`, `dot_tiers`, `dot_operations`, `dot_trigger_types`, `dot_coverage_statuses`) MISSING hoàn toàn, không schema nào, không tên biến thể. (c) `/opt/incomex/migrations` + `/opt/incomex/sql` KHÔNG TỒN TẠI. (d) `dot-migration-s155-p1b` chỉ tạo `dot_domain_rules` + `field_type_equivalences` (2 bảng KHÁC luật §9.2). (e) LG-5 CONFIRMED: `trg_birth_dot_tools` + `birth_trigger_dot_tools` trùng hệt nhau cùng fn + cùng AFTER INSERT + cả hai enabled → mỗi INSERT dot_tools chạy trigger 2 lần. (f) APR: 19 birth_orphan applied (post-facto register DOT scripts) + 1 drift alert, 0 APR bootstrap reference tables.	Báo cáo CLI V2
2026-04-14 #15	🔴 HƯỚNG C′ — CHẮP VÁ CÓ CHỌN LỌC (chính xác hơn hướng C đơn thuần) — Đối chiếu §9.2 luật yêu cầu 7 bảng (dot_domains + dot_coverage_required + dot_config + 4 reference tables) vs thực tế: 2/7 EXIST (dot_domains + dot_coverage_required), 5/7 MISSING. PR #655 chỉ có bash, không tạo 2 bảng kia → nguồn 2 bảng exist CHƯA XÁC ĐỊNH. Handoff S155 ghi "4 SSOT tables DONE" — con số 4 không khớp cả luật (7) lẫn thực tế (2) → handoff đếm mà không kiểm, ghi sổ bằng số không kèm tên. Hệ quả: 1.5 tháng qua Đ36 S155, Đ38 S164, Đ39 S160, Đ41 2026-04-14 đều đứng trên 2/7 bồn rửa thực + 5 bồn ảo + sổ dối. Pattern mới: bootstrap thi công chắp vá — handoff đếm số không đo tên — không ai catch mismatch. Chính Đ35 §1 MT2 "Đo bằng số" bị vi phạm ngay trong bootstrap của chính nó.	Đối chiếu CLI V2 vs luật §9.2 vs handoff S155
2026-04-14 #16	⚠️ CÂU HỎI TREO CẤP 1: Ai đã tạo `dot_domains` + `dot_coverage_required` nếu không phải PR #655/#657? 3 khả năng: (i) PR #656 hoặc #658 (handoff không ghi chi tiết), (ii) migration chạy tay trên VPS không qua PR (đúng pattern Đ41 sinh ra để chặn), (iii) một DOT bash nào đó trong PR #655 gọi psql tạo bảng ẩn (cần grep `CREATE TABLE` trong 9 file bash). Cần verify trước khi quyết hướng fix — vì nếu (iii) thì PR #655 có bootstrap nhưng bootstrap chắp vá chỉ 2/7 bảng → đây là bug chứ không phải missing.	Suy luận từ #14+#15
2026-04-14 #17	✅✅✅ GỐC RỄ CHÍNH XÁC PHƠI BÀY (vector search KB lịch sử) — Đọc `handoff-s151-design-session.md` (2026-03-31 rev 2) phần "SOẠN PROMPT S155-DOT / Scope S155-DOT (1 PR, 3 blocks) / BLOCK 1 — SCHEMA" liệt kê CHÍNH XÁC 4 bảng được scope: (1) dot_domains 24 seed, (2) dot_coverage_required, (3) collection_groups 9 seed (Đ36), (4) collection_field_standards 11 seed (Đ36), + ALTER dot_tools ADD 10 fields + ALTER collection_registry ADD group. 4 reference tables + dot_config KHÔNG CÓ TRONG PROMPT mặc dù luật Đ35 v5.0 §9.2 BLOCK 1 quy định rõ ràng. → Gốc rễ: người soạn prompt S155 (Desktop phiên S151) đã BỎ SÓT 5 bảng khi convert luật §9.2 → scope prompt. Agent CLI thực thi đúng theo prompt → S155 DONE theo prompt → handoff ghi "4 SSOT tables DONE" khớp với số prompt → không ai catch prompt thiếu luật. Bằng chứng phụ củng cố: (a) S161-P2 report (2026-04-04) ghi rõ "dot_tools.trigger_type CHECK allows cron/event/on-deploy/on-demand/manual/one-off" — xác nhận thực tế là CHECK hardcode, KHÔNG phải FK tới `dot_trigger_types` như §4.1 luật yêu cầu. (b) S161-P2 cũng ghi "dot_domains: NO description column" — schema thực lệch luật Phụ lục A Đ35. (c) Report `s155-p1b-report` + `s155-p1c-close-loop-report` + `s155-p2-fk-constraint-report` MẤT TÍCH khỏi KB mặc dù handoff S151 nhắc tới — có nghĩa bằng chứng chi tiết S155 thực sự làm gì không còn truy xuất được qua KB. Chỉ còn handoff (nói chung chung) + S161-P2 (quan sát gián tiếp).	Reading `handoff-s151-design-session.md` full + reading `s161-p2-kg-dot-registration-report` full
2026-04-14 #18	🔴 PATTERN GỐC CỦA GỐC — PROMPT-LAW DRIFT (mới) — Đây là pattern chưa từng được đặt tên trong hệ thống: "Prompt thiết kế bootstrap không đối chiếu đủ các section luật → agent thực thi đúng prompt nhưng thiếu so với luật → handoff báo cáo khớp prompt không khớp luật → bệnh ngầm 1.5 tháng." Pattern này được kích hoạt bởi 3 điều kiện cùng lúc: (E1) luật dài, chia nhiều section (§4 schema + §9 bootstrap — §9 giả định §4 đã đọc), (E2) người soạn prompt chỉ lấy §9 làm scope mà không cross-check §4, (E3) không có checker DOT nào chạy "đối chiếu prompt vs luật" sau khi ban hành. Hệ quả lan rộng: Đ36 (S155 DONE cùng phiên), Đ38 (S164 100% CLOSED), Đ39 (S160 enacted), Đ41 (2026-04-14 vừa ban hành) đều có khả năng cao mắc cùng pattern vì chung cách soạn prompt. Cần audit chéo pattern này ở cả 4 luật sớm.	Khái quát hoá từ #17
2026-04-14 #19	⚠️ BẰNG CHỨNG PHỤ — HANDOFF S155 ĐẾM MÀ KHÔNG KIỂM — Handoff S155 ghi *"4 SSOT tables + 6 DOT + 3 cron	PR #655"* nhưng không liệt kê tên 4 bảng. Nếu handoff ghi tên — "dot_domains, dot_coverage_required, collection_groups, collection_field_standards" — thì Desktop/user phiên sau đối chiếu với luật §4.1 (`dot_tiers`, `dot_operations`, `dot_trigger_types`, `dot_coverage_statuses`) sẽ catch mismatch ngay. Bài học memory: mọi handoff ghi số artifact BẮT BUỘC kèm tên cụ thể. Pattern "đếm số không đo tên" cần ghi anti-pattern mới. Đ35 §1 MT2 "Đo bằng số" bị phản tác dụng khi tên bị giấu.	Đối chiếu handoff S155 vs §4.1 luật
2026-04-14 #20	🟡 LG-5 trigger duplicate — chưa đủ bằng chứng gốc — `trg_birth_dot_tools` + `birth_trigger_dot_tools` cùng trỏ `fn_birth_registry_auto('code')`, cùng AFTER INSERT. Có thể được tạo bởi: (a) migration thủ công chạy 2 lần (không có IF NOT EXISTS), (b) 2 DOT khác nhau cùng setup trigger (dot-birth-trigger-setup + một DOT bootstrap bị quên), (c) rollback nửa vời giữ lại trigger cũ + thêm trigger mới. Cần verify nhưng không gấp bằng #17. Ảnh hưởng: performance + rủi ro nếu `fn_birth_registry_auto` không idempotent.	Suy luận từ CLI V2 step 2
2026-04-14 #21	✅ ĐIỀU TRA 7 VÙNG — LUẬT + OR + HP + ANTI-PATTERNS + TIMELINE + LUẬT KHÁC + PATTERN LẶP. Đọc full: `dieu35-dot-governance-law.md`, `operating-rules-law-drafting.md` v1.0, `operating-rules.md` v7.57-draft, `constitution.md` v4.5.1, `anti-patterns.md` (15 patterns), `handoff-s151-design-session.md` rev 2, `handoff-s155-dot-session.md`, `s161-p2-kg-dot-registration-report`. Kết quả: (a) Đ35 §4 schema VÀ §9.2 BLOCK 1 ĐỀU yêu cầu đủ 7 bảng (không phải luật thiếu). (b) Handoff S151 "SOẠN PROMPT S155-DOT / Scope BLOCK 1 — SCHEMA" liệt kê chính xác 4 bảng: dot_domains, dot_coverage_required, collection_groups, collection_field_standards — BỎ 4 reference tables + dot_config. (c) Agent S155 thực thi đúng prompt → S155 DONE theo prompt. (d) S161-P2 report xác nhận thực tế `dot_tools.trigger_type` dùng CHECK hardcode, KHÔNG phải FK tới `dot_trigger_types` — bằng chứng âm: reference tables không tồn tại lúc S161-P2. (e) Report `s155-p1b/c/p2` MẤT TÍCH khỏi KB — bằng chứng chi tiết S155 thực sự chạy gì không truy xuất được. (f) AP-13 + AP-19 chưa bắt được pattern "prompt bỏ sót section". (g) S164b/c chỉ fix hardcode, không drop table — 5 bảng chưa từng tồn tại, không bị drop.	Tổng hợp 7 vùng
2026-04-14 #22	🔴 ROOT CAUSE CHÍNH XÁC (tầng 4): Tầng 1 triệu chứng: 5 bảng missing + 94% operation NULL + 3 lớp registry + cảnh sát câm. Tầng 2 trực tiếp: prompt S155 thiếu 5 bảng so với §9.2 luật. Tầng 3 process: OR soạn luật `operating-rules-law-drafting.md` §VII Checklist không có mục "Prompt bootstrap phải đối chiếu đủ §4 + §9 luật, ghi tên không ghi số". Tầng 4 gốc gốc: Skill handoff v7 + template handoff BẮT BUỘC 7 mục không bắt buộc ghi TÊN khi ghi số artifact. Handoff S155 "4 SSOT tables" khớp prompt (4) mà không khớp luật (7) → không có cách catch mismatch trong 14 ngày. Đây là lỗ hổng chưa bao giờ bị flag vì chưa có incident đủ lớn.	Đẩy gốc 4 tầng từ #21
2026-04-14 #23	⚠️ CÂU 1 CỦA HUYÊN — LUẬT ĐÃ ĐỦ CHƯA: Nội dung Đ35 v5.0 đủ về schema, thiếu ở tầng OR soạn luật + HP NT + anti-patterns + skill handoff. 4 Gap cần bổ sung: Gap-1 OR soạn luật §VII thêm mục "prompt bootstrap đối chiếu §4+§9 luật, ghi tên". Gap-2 HP/OR thêm NT mới "Sau ban hành luật → DOT-LAW-VERIFY so §4 với pg_catalog". Gap-3 AP-19 mở rộng cho schema (hiện chỉ áp data row) + Đ35 §retrofit clause. Gap-4 skill handoff + anti-pattern AP-22 mới "Đếm số không đo tên".	Phân tích khung 3 câu
2026-04-14 #24	🔴 CÂU 2 — 7 SAI ĐÃ LÀM + TẠI SAO + BIỆN PHÁP TRIỆT ĐỂ (ghi đầy đủ trong §10 bên dưới). Tóm: S-1 (5 bảng missing), S-2 (94% operation NULL), S-3 (3 lớp registry trùng), S-4 (Lớp 3 phantom coverage=complete), S-5 (244 mồ côi), S-6 (handoff đếm số không tên), S-7 (trigger duplicate). Biện pháp triệt để: PG-cấp UNIQUE/NOT NULL + DB trigger chặn + DOT-LAW-VERIFY + fix curl silent-fail + OR soạn luật checklist + skill handoff ghi tên.	Phân tích khung 3 câu
2026-04-14 #25	⚪ CÂU 3 — CHƯA LÀM GÌ + VĨNH VIỄN: (1) Amend Đ35 v5.0→v5.1 (§4.1 UNIQUE/NOT NULL, §8.1 H10-H13, §9.2 idempotent + đủ 7 tên, §9.3 enforce hết grace, §retrofit clause). (2) Amend OR soạn luật v1.0→v1.1 (+checklist Gap-1). (3) Thêm AP-22 + AP-23 anti-patterns. (4) Chạy migration hoàn tất BLOCK 1 + retrofit 272 DOT SAU khi v5.1 ban hành. (5) Audit chéo Đ36+Đ38+Đ39 tìm pattern PROMPT-LAW DRIFT. (6) Tìm S155 report mất tích. (7) Sau Đ35 vững → Phase 0 dọn registry → Phase 1 Đ41.	Phân tích khung 3 câu
2026-04-14 #26	✅ COUNCIL ROUND 1 DONE (Fix 8 chiều). Soạn draft v5.1 rev 1 (4 khoản + §11 retrofit). Gửi Gemini + GPT. Kết quả: cả 2 APPROVE WITH CHANGES. Gemini 9/10 + GPT 8.3/10. 5 blocker: B1 fn_is_in_grace_period chưa định nghĩa, B2 fn_log_issue chưa định nghĩa, B3 _dot_origin lệch §4.1 vs §5/§8, B4 UNIQUE partial wording sai kỹ thuật (45 dup non-null sẽ FAIL), B5 dual-trigger flow PATCH-after-insert chết khi mode=block. 5 non-blocker: tiêu chí cứng warn→block, SECDEF search_path, §11.4 wording cứng, rule APR auto-backfill, payload NT11 wording. Fix toàn bộ → rev 2.	Reports `council-review-dieu35-v5-1-{gemini,gpt}-round1.md`
2026-04-14 #27	✅ COUNCIL ROUND 2 DONE (Fix 8 tối). Rev 2 sau 5 blocker fix + 5 non-blocker fix + sửa lỗi viện dẫn NT12/NT13 (HP v4.5.1 chỉ có 11 NT). Gửi R2. Kết quả: Gemini 9.8/10 APPROVE FINAL + GPT 9.1/10 APPROVE WITH MINOR. GPT phát hiện 7 minor inline fix: (1) dot_config NOT NULL mâu thuẫn seed NULL, (2) fn_log_issue signature có severity → warning→critical đẻ 2 row, (3) thiếu precheck dedupe system_issues, (4) §5.1 chưa viết cứng infer fail CẤM POST, (5) H13 self-paradox, (6) BLOCK 4 thiếu 4.0 snapshot + 4.3 lưu old_file_path + 4.10 atomic + 4.13 cleanup, (7) Gemini thêm 4.0 snapshot. Apply inline → v5.1 FINAL.	Reports `council-review-dieu35-v5-1-{gemini,gpt}-round2.md`
2026-04-14 #28	✅✅✅ BAN HÀNH Đ35 v5.1 FINAL (Fix 8 đêm). 0 blocker còn lại. Thao tác trên KB: (a) overwrite `dieu35-dot-governance-law.md` v5.0 → v5.1 FINAL (rev 2), (b) backup v5.0 tại `dieu35-dot-governance-law-v5-0-backup.md` rev 1 (AP-21), (c) draft v5.1 đánh dấu SUPERSEDED rev 11 (giữ trace Council), (d) HP cập nhật mục lục Đ35 + changelog v4.5.2 rev 17, (e) memory #24 ghi nhận + 5 post-merge TODO, (f) handoff-s177-fix8-session.md rev 1 + 12 TODO. Chuyển sang pha triển khai thực tế — §13.5 có 14 TODO chi tiết.	6 file KB updates

§10. 3 CÂU TRẢ LỜI CHUẨN CHO HUYÊN (khung 3-nguyên-tắc)

§10.1 — CÂU 1: LUẬT ĐÃ ĐỦ CHƯA?

Kết luận: Đ35 v5.0 nội dung đủ. THIẾU ở 4 chỗ khác — không phải lỗi Đ35, lỗi khung soạn luật và khung verify sau ban hành.

Gap	Tên	Thuộc văn bản	Bổ sung
Gap-1	Prompt bootstrap không đối chiếu đủ section luật	OR soạn luật §VII	Checklist mục 9: "Prompt bootstrap phải đối chiếu từng dòng §4 schema + §9 bootstrap luật, ghi tên artifact KHÔNG ghi số thuần"
Gap-2	Sau ban hành luật không có verify tự động	HP NT mới HOẶC Đ35 §11 mới	"DOT-LAW-VERIFY chạy baseline: so §4 schema luật với pg_catalog thực tế. Lệch = pending APR. Chạy ngay sau luật ban hành + cron weekly"
Gap-3	Luật mới không hồi tố cho schema (chỉ hồi tố data)	anti-patterns.md AP-19 mở rộng + Đ35 §retrofit clause	AP-19 thêm "áp cho cả schema table/column/constraint, không chỉ row". Đ35 §retrofit: "mọi entity vi phạm luật mới → DOT-DOT-RETROFIT tạo APR backfill metadata + fix constraint"
Gap-4	Handoff ghi số không đo tên	skill-handoff-quality.md + anti-pattern AP-22 mới	"Mọi handoff ghi N artifact BẮT BUỘC kèm danh sách tên. DOT-HANDOFF-LINT scan handoff, flag nếu có 'N tables/DOT/files' không kèm tên"

§10.2 — CÂU 2: ĐÃ LÀM GÌ SAI LUẬT + TẠI SAO + BIỆN PHÁP TRIỆT ĐỂ

#	Sai	Vi phạm luật nào	Tại sao (evidence)	Biện pháp triệt để
S-1	5 bảng §4.1 missing trên VPS	Đ35 §4.1 + §9.2 BLOCK 1	Prompt S155 (handoff S151) liệt kê 4 bảng bỏ sót 5	Gap-1 + Gap-2: DOT-LAW-VERIFY so §4 với pg_catalog sau mỗi ban hành luật. PG function `fn_law_verify_schema()` chạy tự động qua Đ22 self-healing. Lỗi không lòi: impossible vì CI chặn nếu pg_catalog không khớp §4
S-2	94% dot_tools.operation NULL (255/272)	Đ35 MT1+MT2 tinh thần, không vi phạm §4.1 trực tiếp (nullable hợp pháp)	`dot-dot-register` chỉ set 6/10 fields khi register	Đ35 v5.1 §4.1 thêm NOT NULL cho operation + coverage + trigger_type sau grace. Fix `dot-dot-register` set đủ 10/10. PG trigger chặn INSERT row thiếu metadata. Lỗi không lòi: PG reject INSERT nếu NULL
S-3	3 lớp registry trùng, 45 cặp duplicate	Đ35 §2 SSOT + HP NT1 "làm 1 lần"	Thiếu UNIQUE(file_path)	Đ35 v5.1 §4.1 thêm `UNIQUE(file_path) WHERE file_path IS NOT NULL`. Lỗi không lòi: PG reject INSERT row thứ 2 trỏ cùng file
S-4	Lớp 3 coverage='complete' + file_path .ts sai 100%	Đ35 §8.1 H4 + HP NT9	`dot-dot-health` H4 có code nhưng `curl \|\| true` silent-fail	Fix curl fail-loud. Thay HTTP call bằng PG function `fn_log_issue()` (INSERT system_issues trực tiếp). Lỗi không lòi: PG function không thể silent-fail như HTTP
S-5	244 file mồ côi	Đ35 §8.1 H7 + Đ0-G	`dot-dot-register` on-deploy không catch file mới	`dot-dot-register` cron weekly + on-deploy + on-demand triple-trigger. Đ35 §8.3 bổ sung. Lỗi không lòi: 3 trigger độc lập, ít nhất 1 sẽ catch
S-6	Handoff S155 "4 SSOT tables" không kèm tên	HP NT10 "Quản lý bằng PG" + NT9	Skill handoff không bắt buộc ghi tên	AP-22 + skill handoff §7 bắt buộc kèm tên. DOT-HANDOFF-LINT scan. Lỗi không lòi: lint block handoff có "N artifact" không kèm danh sách
S-7	`trg_birth_dot_tools` + `birth_trigger_dot_tools` duplicate	HP NT1 "làm 1 lần"	Migration không có DROP TRIGGER IF EXISTS	Đ35 v5.1 §9.2 bắt buộc mọi CREATE TRIGGER có DROP IF EXISTS trước. `dot-dot-health` thêm H13 check trigger duplicate. Lỗi không lòi: bootstrap script idempotent, health check catch drift

§10.3 — CÂU 3: CHƯA LÀM → LÀM GÌ VĨNH VIỄN

Thứ tự bắt buộc (không nhảy bước):

Amend Đ35 v5.0 → v5.1 (NT9 luật trước): §4.1 UNIQUE+NOT NULL, §8.1 H10-H13, §9.2 idempotent đủ 7 tên, §9.3 enforce hết grace, §retrofit clause mới. Council nhanh (không đụng HP)
Amend OR soạn luật v1.0 → v1.1: §VII checklist Gap-1
Thêm AP-22 + AP-23 + mở rộng AP-19 vào anti-patterns.md
Thêm NT14 vào HP (hoặc §11 Đ35): DOT-LAW-VERIFY bắt buộc sau ban hành luật
Audit chéo Đ36/Đ38/Đ39/Đ41 — chạy DOT-LAW-VERIFY ngay sau khi build, phát hiện PROMPT-LAW DRIFT ở luật nào khác
Tìm report S155-P1b/c/P2 mất tích (VPS disk + git log)
Khi v5.1 ban hành + audit chéo xong: chạy migration hoàn tất BLOCK 1 + retrofit 272 DOT
Sau Đ35 nền tảng vững: Phase 0 dọn registry (244 mồ côi + 60 shell + 6 phantom + 45 duplicate) → Phase 1 Đ41 tạo vps_deploy_log

§10.4 — PATTERN MỚI ĐẶT TÊN

PROMPT-LAW DRIFT — prompt bootstrap scope thiếu so với luật → agent thực thi đúng prompt, sai so với luật → handoff báo cáo khớp prompt không khớp luật → bệnh ngầm. Kích hoạt bởi 3 điều kiện: (E1) luật dài, §4 và §9 giả định nhau đã đọc, (E2) người soạn prompt chỉ lấy 1 section, (E3) không có verify sau ban hành.

AP-22 "Đếm số không đo tên" — handoff/report ghi N artifact không kèm danh sách tên → không có cách catch mismatch giữa số prompt và số luật.

§11. BỨC TRANH ĐÃ ĐẢO NGƯỢC LẦN 2 — GỐC 5 TẦNG (2026-04-14 S177 chiều, sau rà lịch sử chat)

Rà lịch sử chat sâu: handoff-s146, handoff-s151-design, handoff-s155-dot, handoff-s161, handoff-s165, handoff-s165-kb, s146-m4d-a-dot-classification-audit, birth-procedures.md v3.0, birth-registry-law.md v1.0, anti-patterns.md AP-21 + AP-KB-DELTA.

§11.1 — Timeline 7 bước (thật chặt)

Ngày	Phiên	Sự kiện	Bằng chứng cứng
2026-03-29	S146	152 DOT, schema chỉ có `code/name/category/description` — không có 10 fields luật mới	`s146-m4d-a-dot-classification-audit` rev 1
2026-03-31	S151	Đ35 v5.0 BAN HÀNH. File gốc `architecture/dieu35-dot-governance-law-draft.md` rev 7	`handoff-s151-design-session.md` rev 2
2026-04-01	S155	Bootstrap theo prompt: scope 4 bảng (dot_domains + dot_coverage_required + collection_groups + collection_field_standards). ALTER dot_tools ADD 10 fields nullable	Handoff S151 §"Scope S155-DOT BLOCK 1 — SCHEMA"
2026-04-04	S161	Schema dot_tools thực tế vẫn 7 fields (code, name, tier, domain, paired_dot, trigger_type, cron_schedule, extra_metadata). THIẾU operation, file_path, coverage_status, last_executed	`handoff-s161-session.md` rev 3
~2026-04-04/05	S165	Phát hiện Đ35/Đ36/Đ26/OR bị cắt cụt do §AP-KB-DELTA. Đ35 thiếu §1-§8	`handoff-s165-session.md` rev 1
~2026-04-05	S165-KB	KHÔI PHỤC Đ35 bằng `conversation_search` ghép chat history + council reviews. 6,865 → 19,174 chars (+3x). File gốc `architecture/*draft.md` bị xoá/move	`handoff-s165-kb-session.md` rev 1
2026-04-07	S170	AP-21 lần 2: Đ36 bị ghi đè bằng v5.0 DRAFT tóm tắt. NĐ-36-01 upload bản tóm tắt thay bản đầy đủ	`anti-patterns.md` AP-21
2026-04-14	S177	CLI verify 5 bảng missing + 94% operation NULL. Em đọc `laws/dieu35-dot-governance-law.md` rev 1 = bản S165-KB khôi phục	Em thử `get_document architecture/dieu35-*draft.md` = 404

§11.2 — GỐC 5 TẦNG

Tầng 1 triệu chứng: 5 bảng missing, 94% operation NULL, 3 lớp registry, cảnh sát câm
Tầng 2 trực tiếp: prompt S155 scope 4 bảng, thiếu 5
Tầng 3 process: OR soạn luật §VII không có checklist cross-check prompt vs luật. Handoff ghi "4 SSOT tables" không kèm tên
Tầng 4 meta-process: §AP-KB-DELTA — agent upload delta, ghi "Giữ nguyên §X-§Y", kb_documents overwrite không version history → mất file gốc Đ35 §1-§8
Tầng 5 (GỐC NHẤT): kb_documents collection từ đầu không có trigger backup + không có version history. Luật Đ0-G Khai sinh bảo vệ entity data nhưng không bảo vệ nội dung LUẬT. Luật của hệ thống tự nó không được bảo vệ bởi luật nào — vòng kim cô gà-trứng

→ Không có cái bảo vệ LUẬT → luật bị mất → viết lại bằng chat history (có thể sai lệch) → không ai catch → bootstrap hỏng → 272 DOT hỏng → mọi thứ hỏng. Đây là bệnh gốc nhất của toàn hệ thống.

§11.3 — "Sinh rồi mới khai" (Huyên linh cảm đúng)

Anh nhớ "thoang thoảng" là đúng:

QT-001 backfill + QT-002 birth-first (birth-procedures.md v3.0) + Đ0-G v1.0 CHỈ lo birth_registry row
KHÔNG có luật nào quy định: entity đã khai sinh → metadata trong bảng nguồn (dot_tools.operation, coverage_status, file_path...) phải đầy đủ
KHÔNG có luật nào quy định: LUẬT (text trong kb_documents) đã ban hành → phải có version history, trigger backup, DOT canh gác nội dung
6 DOT inspector Đ0-G (inspect_pen/stamp/gate) design cho birth_registry row — KHÔNG cho metadata nguồn, KHÔNG cho nội dung luật
Gap hiện tại: "khai sinh thoang thoảng" = có row birth = certified. Thực tế "đầy đủ" đòi hỏi metadata trong bảng nguồn phải đủ — không luật nào nói

§11.4 — 3 GAP LỚN BỔ SUNG (ngoài 4 Gap §10.1)

★ CẬP NHẬT 2026-04-14 S177 tối — Gap-5 ĐÃ GIẢI QUYẾT: Sau rà thêm kb-protection-phase1-report, kb-phase2-deploy-verification, s170-kb-phase2-restore-report, s170-final-kb-v2-report. Phạm vi bảo vệ = kb_documents ONLY (xác nhận Huyên 2026-04-14). KHÔNG cần Điều 42 MỚI — 2 cơ chế Phase 1 + Phase 2 đã được thiết kế + deploy (S165 + S167 + S170). Chi tiết §12.

Gap	Mức	Mô tả
~~Gap-5: LAW-PROTECTION~~	✅ CLOSED	Đã có 2 cơ chế: Phase 1 (4 trigger kb_documents) + Phase 2 (INSERT mode history + updated_at auto). Phạm vi = `kb_documents` only. Chi tiết §12. Chỉ cần verify đang chạy + fix nếu broken — KHÔNG cần luật mới.
Gap-6: METADATA-AFTER-BIRTH	🔴 CRITICAL	Đ0-G "khai sinh" chỉ tới birth_registry row. Không có luật "metadata trong bảng nguồn phải đầy đủ sau khai sinh". Không có DOT inspector cho metadata nguồn. Cần amend Đ0-G hoặc Đ35 thêm §"complete metadata check" + DOT `dot-metadata-completeness`
Gap-7: KHẢ NĂNG B không loại trừ	🟡 MEDIUM	File gốc Đ35 S151 đã bị xoá/move sau S165-KB, không còn cách verify bản gốc yêu cầu 4 hay 7 bảng. Không đủ bằng chứng chốt A hay B. Nhưng KHÔNG thay đổi biện pháp fix — dù A hay B vẫn cần Gap-1 đến Gap-4 + Gap-6

§11.5 — 4 ĐIỀU TRA BỔ SUNG (nếu muốn chốt 100%)

E-1: Tìm file gốc Đ35 S151 — git log /opt/incomex + git log local Huyên. Còn backup → so sánh §9.2 gốc
E-2: Kiểm tra VPS có collection_groups + collection_field_standards không. Có → củng cố A. Không → khả năng B (bảng bị drop sau)
E-3: conversation_search chat S151 gốc — nội dung §9.2 luật gốc có trong chat không
E-4: kb_audit_log (nếu tồn tại) có ghi history updates cho dieu35-* không

KHÔNG gấp — dù kết quả A hay B, biện pháp fix (Gap-1 → Gap-6) đều áp dụng được. Gap-5 đã CLOSED.

§12. KB PROTECTION PHASE 1 + PHASE 2 — 2 CƠ CHẾ BẢO VỆ `kb_documents` ĐÃ TRIỂN KHAI

Ngày ghi: 2026-04-14 S177 tối, sau rà 4 report lịch sử + conversation_search Phạm vi: CHỈ kb_documents trong DB incomex_metadata (chốt Huyên 2026-04-14). File script/config/code KHÔNG cover bởi 2 cơ chế này — data nghiệp vụ dùng cơ chế PG riêng (trigger/FK/audit ở directus DB). Mục đích phụ lục §12: Ghi đầy đủ timeline + cơ chế + các lần sửa + trạng thái verify, để không phải search lại mỗi phiên. Kết luận: KHÔNG cần Điều 42 MỚI. Chỉ cần verify 2 cơ chế có đang chạy thật trên VPS hôm nay không, chưa thì fix. Nếu vẫn chạy → đóng sổ, bỏ qua Gap-5.

§12.1 — BỐI CẢNH: Tại sao có 2 cơ chế này

Sau 2 tai nạn AP-21 mất file luật (em đã rà):

Lần	Ngày	Tai nạn	Phát hiện tại
1	~S157	Đ37 bị cắt cụt §1-§12 → chỉ còn 2,297 chars. Agent upload delta "Giữ nguyên §X-§Y", kb_documents overwrite không backup. Khôi phục S165 bằng ghép chat history → 15,148 chars	S165 phát hiện khi check 81 files luật
2	~S170	Đ36 v4.0 enacted bị ghi đè bằng v5.0 DRAFT tóm tắt 2K chars. NĐ-36-01 upload bản tóm tắt thay bản đầy đủ. Đ35 cũng mất §1-§8 phải khôi phục ghép chat history	S170 + AP-21 anti-pattern

→ Sau tai nạn lần 2, 2 cơ chế bảo vệ được thiết kế và triển khai. Đây chính xác là "2 nội dung bảo vệ" mà anh nhắc.

§12.2 — CƠ CHẾ #1: VERSION HISTORY TRIGGER (ảnh chụp trước khi sửa)

Nguồn: reports/kb-protection-phase1-report — Deploy 2026-04-04 (S165)

Cơ chế hoạt động (nôm na):

Giống tủ lưu bản vẽ có camera. Mỗi lần ai vào sửa bản vẽ, camera tự chụp ảnh bản cũ TRƯỚC khi cho sửa. Ảnh cũ lưu trong kho riêng, người sửa không xoá được.

Triển khai kỹ thuật:

Thành phần	Vai trò
`kb_documents_history` (table)	Kho lưu mọi version cũ của kb_documents. Full JSONB snapshot trước mỗi UPDATE/DELETE
`kb_audit_log` (table)	Log nhẹ mọi write operation (INSERT/UPDATE/DELETE) — metadata only, không lưu content
`trg_kb_snapshot_update`	Trigger BEFORE UPDATE — copy OLD.data vào history
`trg_kb_snapshot_delete`	Trigger BEFORE DELETE — copy OLD.data vào history
`trg_kb_audit`	Trigger AFTER INSERT/UPDATE/DELETE — log metadata
`trg_kb_truncation_guard`	Trigger BEFORE UPDATE — WARN nếu content shrink > 80%
`fn_kb_snapshot()`	Function thực thi snapshot (workflow_admin, SECURITY DEFINER)
`fn_kb_restore(key, timestamp)`	Function khôi phục từ history về thời điểm bất kỳ

Safety design: Mọi trigger dùng EXCEPTION WHEN OTHERS THEN RAISE WARNING — không block production writes. Nghĩa là trigger fail → write vẫn qua, chỉ mất history → cần verify trigger còn sống.

DOT pair (Đ35 §8 CP-12):

DOT_KB_PROTECT (Tier B, event trigger) — thực thi bảo vệ
DOT_KB_VERIFY (Tier A, cron daily 21:00 UTC) — kiểm tra integrity
DOT_KB_RESTORE (Tier B, on-demand) — khôi phục thủ công khi cần

Cron canh gác:

0 21 * * * /opt/incomex/scripts/dot-kb-verify.sh >> /var/log/incomex/dot-kb-verify.log 2>&1

§12.3 — CƠ CHẾ #2: `updated_at` AUTO-TIMESTAMP (đóng dấu thời gian sửa)

Nguồn: reports/kb-phase2-deploy-verification — Deploy 2026-04-05 (S167)

Cơ chế hoạt động (nôm na):

Mỗi lần sửa file, hệ thống tự đóng dấu thời gian "sửa lần cuối: ngày/giờ". Không ai đóng tay. Không ai sửa được dấu này sau khi đóng.

Triển khai kỹ thuật:

Thành phần	Vai trò
`kb_documents.updated_at` (column)	Timestamp NOT NULL. Auto-update mỗi UPDATE
`fn_kb_updated_at()`	Trigger function set `NEW.updated_at = NOW()`
`fn_kb_restore(key, timestamptz)`	Khôi phục theo timestamp từ history

Verify PASS (2026-04-05 S167):

updated_at column created, NOT NULL ✅
Auto-update test: 2026-04-05 05:42:39 → 2026-04-05 08:10:11 sau UPDATE ✅
UNIQUE constraint uq_kb_history_document_key dropped ✅ (cho phép nhiều history rows/doc)
526 history rows, 134 docs multi-version ✅
API health 872 docs, 1319 vectors ✅
dot-kb-verify v3.0.0 12/12 PASS ✅

§12.4 — LỊCH SỬ SỬA CHỮA 2 CƠ CHẾ (Huyên nhắc: "đã cho sửa lại 2 nội dung này 1 lần nhưng có vẻ vẫn chưa chạy")

Em tìm thấy 2 LẦN SỬA trong lịch sử — không phải 1:

Sửa lần 1 — S170 v2 (2026-04-06): INSERT → UPSERT (bounded growth)

Nguồn: reports/s170-final-kb-v2-report

Thay đổi	Trước	Sau
fn_kb_snapshot mode	INSERT (unbounded)	UPSERT (ON CONFLICT DO UPDATE)
History rows per doc	Không giới hạn	Đúng 1 row/doc forever
UNIQUE constraint	Không có	`uq_kb_history_document_key`
Permission `incomex`	Có DELETE/TRUNCATE	REVOKED
dot-kb-verify.sh	v1 (ít check)	v2.0.0 (+Check 7 permission guard)
cron-env.sh	644	chmod 600 root-only

Lý do sửa lần 1: Lo ngại history grow vô hạn (856 docs × 100 updates/ngày = 85,600 rows/ngày). Chuyển UPSERT để bounded.

Sửa lần 2 — S170-KB-PHASE2 restore + lock (2026-04-06): QUAY LẠI INSERT mode

Nguồn: reports/s170-kb-phase2-restore-report

Thay đổi	Lần 1 (UPSERT)	Lần 2 (restore)
fn_kb_snapshot mode	UPSERT	QUAY LẠI INSERT (đầy đủ version)
UNIQUE constraint	Có	DROPPED lại
History rows per doc	1 row	Nhiều row = full version history
Owner functions	incomex?	workflow_admin (SECURITY DEFINER)
`incomex can ALTER` functions?	—	❌ "must be owner"
`incomex can DELETE` history?	REVOKED	❌ "permission denied"
`kb_config.history_retention_days`	—	60 (prune cronjob đọc từ config)
`fn_kb_prune_history()`	—	Mới (SECURITY DEFINER, xoá rows > 60 ngày)
dot-kb-verify.sh	v2.0.0	v3.0.0 (12 checks)

Lý do sửa lần 2: UPSERT làm mất history cũ (chỉ giữ 1 row/doc → không khôi phục được revision giữa). Quay lại INSERT mode để giữ full history, nhưng bảo vệ bằng:

Owner lock (workflow_admin)
Retention config 60 ngày (prune tự động)
Permission guard (incomex không thể DELETE)

Verify PASS lần 2 (2026-04-06):

fn_kb_snapshot mode = INSERT ✅
fn_kb_snapshot RETURN NEW (UPDATE) / OLD (DELETE) ✅
UNIQUE dropped ✅
1,948 history rows, 206 unique docs, 158 multi-version ✅
Security test: incomex KHÔNG ALTER function/DELETE history ✅
Normal writes vẫn qua: 1946 → 1947 history ✅
dot-kb-verify 12 checks: 10 PASS + 2 WARN (law move truncation — expected)

§12.5 — HUYÊN NHẮC: "VẪN CHƯA CHẠY"

Anh nhắc "đã cho sửa lại 2 nội dung này 1 lần nhưng có vẻ vẫn chưa chạy". Em tìm được evidence của 2 lần sửa S170 nhưng không có evidence nào cho thấy trạng thái HÔM NAY (2026-04-14, 8 ngày sau S170).

3 điểm nghi ngờ cần verify trên VPS hôm nay:

Nghi ngờ	Bằng chứng gián tiếp
N-1: Trigger có thể bị drop/disable sau S170	CLI V2 report S177 (2026-04-14) phát hiện LG-5 trigger duplicate trên `dot_tools` (trg_birth_dot_tools × 2) — chứng tỏ có ai đó động vào trigger system. Không rõ có động vào 4 trigger `kb_documents` không
N-2: Cron dot-kb-verify có thể không chạy	S174 (2026-04-08) phát hiện `dot-dot-health` silent-fail `curl \|\| true`. Pattern cron câm có thể lan sang dot-kb-verify
N-3: Permission có thể bị drift	S176 AP-IAM-RESET-PATTERN — pattern credential/permission bị reset định kỳ. `REVOKE DELETE FROM incomex` có thể bị restore sau migration nào đó

KHÔNG thể kết luận 2 cơ chế còn chạy hay không nếu không verify trực tiếp. Cần CLI.

§12.6 — PROMPT CLI VERIFY (5 câu, read-only, ~3 phút)

Mission code: S177-KB-PROTECTION-VERIFY Mục tiêu: Xác định 2 cơ chế bảo vệ kb_documents (Phase 1 + Phase 2) có ĐANG HOẠT ĐỘNG trên VPS hôm nay không. Scope: CHỈ kb_documents in incomex_metadata. KHÔNG đụng file script/config.

# MISSION: S177-KB-PROTECTION-VERIFY

## CHECKPOINT
- [ ] Đọc §12 phụ lục Đ41 (2 cơ chế + 2 lần sửa S170)
- [ ] PRECHECK: ssh vps + docker exec postgres + psql OK

## CONSTRAINTS
- CHỈ ĐỌC. KHÔNG INSERT/UPDATE/DELETE/DDL.
- Query DB `incomex_metadata` (KHÔNG phải `directus`).
- Dùng bash + ssh + docker exec + psql thẳng.

## 5 CÂU VERIFY

### C1 — 4 trigger Phase 1 có còn tồn tại + enabled không?
ssh vps "docker exec postgres psql -U postgres -d incomex_metadata -c \"
  SELECT tgname, tgenabled, 
         CASE tgtype::int & 66 WHEN 2 THEN 'BEFORE' WHEN 64 THEN 'INSTEAD OF' ELSE 'AFTER' END AS timing
  FROM pg_trigger 
  WHERE tgrelid='kb_documents'::regclass 
    AND NOT tgisinternal
  ORDER BY tgname;
\""
# Expected: 4 trigger (trg_kb_truncation_guard, trg_kb_snapshot_update, trg_kb_snapshot_delete, trg_kb_audit), tgenabled='O'

### C2 — kb_documents_history có data mới gần đây không?
ssh vps "docker exec postgres psql -U postgres -d incomex_metadata -c \"
  SELECT COUNT(*) AS total_rows,
         COUNT(DISTINCT document_key) AS unique_docs,
         MAX(snapshot_at) AS latest_snapshot,
         AGE(NOW(), MAX(snapshot_at)) AS age_since_latest
  FROM kb_documents_history;
\""
ssh vps "docker exec postgres psql -U postgres -d incomex_metadata -c \"
  SELECT COUNT(*) AS total_docs,
         COUNT(updated_at) AS with_updated_at,
         MAX(updated_at) AS latest_update,
         AGE(NOW(), MAX(updated_at)) AS age_since_latest_update
  FROM kb_documents;
\""
# Expected: latest_snapshot và latest_update < 24h (nếu có write hôm nay). 
# Nếu age > 7 ngày = trigger có thể không fire HOẶC không có write (kiểm tra C5 audit log)

### C3 — Owner + SECURITY DEFINER còn nguyên không?
ssh vps "docker exec postgres psql -U postgres -d incomex_metadata -c \"
  SELECT proname, 
         pg_get_userbyid(proowner) AS owner, 
         prosecdef AS security_definer
  FROM pg_proc 
  WHERE proname IN ('fn_kb_snapshot','fn_kb_audit','fn_kb_restore',
                    'fn_kb_truncation_guard','fn_kb_updated_at','fn_kb_prune_history')
  ORDER BY proname;
\""
ssh vps "docker exec postgres psql -U postgres -d incomex_metadata -c \"
  SELECT grantee, table_name, privilege_type 
  FROM information_schema.table_privileges 
  WHERE table_name IN ('kb_documents_history','kb_audit_log') 
    AND grantee IN ('incomex','workflow_admin')
  ORDER BY table_name, grantee, privilege_type;
\""
# Expected: Owner = workflow_admin, security_definer = true (fn_kb_snapshot ít nhất).
# incomex KHÔNG được có DELETE/TRUNCATE trên kb_documents_history, kb_audit_log.

### C4 — Cron dot-kb-verify có chạy + last log mới không?
ssh vps "sudo crontab -l -u root 2>/dev/null | grep -i 'kb-verify\|dot-kb' || crontab -l 2>/dev/null | grep -i 'kb-verify\|dot-kb'"
ssh vps "ls -la /var/log/incomex/dot-kb-verify.log 2>/dev/null"
ssh vps "tail -30 /var/log/incomex/dot-kb-verify.log 2>/dev/null"
ssh vps "stat /opt/incomex/scripts/dot-kb-verify.sh 2>/dev/null | grep -E 'File|Modify'"
# Expected: 
# - Cron entry: '0 21 * * * /opt/incomex/scripts/dot-kb-verify.sh'
# - Log mtime < 24h (cron chạy hôm qua 21:00 UTC)
# - Log cuối cùng có "RESULT: PASS" hoặc "PASS/WARN"

### C5 — kb_audit_log hoạt động, có write recent không?
ssh vps "docker exec postgres psql -U postgres -d incomex_metadata -c \"
  SELECT operation, COUNT(*) AS n, MAX(logged_at) AS latest, AGE(NOW(), MAX(logged_at)) AS age
  FROM kb_audit_log
  WHERE logged_at > NOW() - INTERVAL '7 days'
  GROUP BY operation ORDER BY operation;
\""
# Expected: Có rows INSERT/UPDATE trong 7 ngày qua. Nếu 0 rows = audit trigger câm.

## VERIFY OUTPUT
File: reports/s177-kb-protection-verify-20260414.md chứa:
1. Output raw từng câu C1-C5
2. Bảng kết luận 5 dòng:
   | # | Cơ chế | Trạng thái | Bằng chứng |
   | 1 | Phase 1 — 4 trigger kb_documents | PASS/WARN/FAIL | ... |
   | 2 | Phase 2 — updated_at auto-update | PASS/WARN/FAIL | ... |
   | 3 | Owner + SECURITY DEFINER lock | PASS/WARN/FAIL | ... |
   | 4 | Cron dot-kb-verify | PASS/WARN/FAIL | ... |
   | 5 | kb_audit_log recent activity | PASS/WARN/FAIL | ... |
3. 1 câu kết luận cuối: "2 cơ chế bảo vệ kb_documents HIỆN ĐANG: [HOẠT ĐỘNG / BỊ DRIFT / CHẾT / KHÔNG RÕ]"

## AP-CLOSE
- KHÔNG commit gì, KHÔNG tạo file ngoài reports/
- Báo về chat: path báo cáo + 5 dòng tóm tắt (mỗi C 1 dòng) + 1 câu kết luận

§12.7 — NẾU VERIFY PHÁT HIỆN DRIFT → FIX THEO 1 TRONG 3 HƯỚNG

Trạng thái phát hiện	Biện pháp
A. HOẠT ĐỘNG — 5/5 PASS	Đóng Gap-5. Ghi tracker "KB protection verified 2026-04-14 PASS". Không làm gì thêm
B. DRIFT một phần — 1-2 check FAIL	Phân tích cụ thể từng check fail + fix theo pattern S170-restore (chạy lại SQL migration `kb_protection_phase2_full_history.sql`). PR mới, không amend luật
C. CHẾT hoàn toàn — 3+ check FAIL	Nghiêm trọng. Có thể có rollback ẩn hoặc drop trigger. Cần điều tra gốc thêm trước khi restore — không vội fix ngọn

Không cần Điều 42 MỚI trong cả 3 hướng. Luật hiện tại + 2 cơ chế đã đủ.

§12.8 — PHẠM VI XÁC NHẬN (2026-04-14 chốt Huyên)

Bảo vệ cái gì	Bằng cơ chế nào	Ghi chú
`kb_documents` (luật + handoff + report)	Phase 1 + Phase 2 đã deploy	Phạm vi chính thức. §12 phụ lục Đ41 là SSOT
Data nghiệp vụ (`directus` DB)	Cơ chế PG riêng — trigger/FK/audit/birth_registry	Có rồi, không nằm trong scope §12
File script/config disk (`/opt/incomex/dot/bin/*`, nginx.conf...)	KHÔNG có cơ chế tương đương	Đ41 v1.0 vừa ban hành là cơ chế mới cho layer này (app-dev/app-production, atomic deploy, vps_deploy_log). CHƯA implement
Code app (Nuxt, agent-data)	Git VPS → GH backup 2×/ngày	Đã có

→ Gap-5 LAW-PROTECTION chốt CLOSED (dùng 2 cơ chế hiện có, không luật mới).

§12.9 — 4 LẦN AP-21 ĐÃ XẢY RA + LẦN NÀO SAU KHI CÓ PHASE 1+2?

Lần	Ngày	Tai nạn	Trước/Sau Phase 1+2?
1	~S157 (2026-04-02)	Đ37 cắt cụt	TRƯỚC (Phase 1 deploy S165 = 2026-04-04)
2	~S170 (2026-04-07)	Đ36 v4.0 overwrite + NĐ-36-01	SAU Phase 1+2 (deploy 2026-04-04+05)
3?	2026-04-14 S177	File gốc Đ35 `architecture/*draft.md` đã bị xoá/move (em phát hiện hôm nay)	SAU — nhưng không rõ khi nào xoá
4?	?	?	?

⚠️ QUAN TRỌNG: Lần 2 (S170 Đ36 overwrite) xảy ra SAU khi Phase 1+2 đã deploy. Nghĩa là cơ chế bảo vệ KHÔNG chặn được tai nạn đó — chỉ WARN (trigger truncation guard raise warning, không block write). Đây là thiết kế cố ý (memory: "never block production writes") nhưng vẫn là lỗ hổng:

Warning ≠ Block. Agent upload bản ngắn → trg_kb_truncation_guard raise WARNING → log → nhưng write vẫn qua → history được lưu (có thể restore) → nhưng không ai đọc warning nên không ai biết cần restore.

Cần điều tra E-5: kb_audit_log có bao nhiêu truncation warnings trong tháng 4/2026? Bao nhiêu được xử lý (restore)? Bao nhiêu bị bỏ qua? Đây là thước đo thực sự của 2 cơ chế.

§12.10 — CẬP NHẬT KHI CLI VERIFY VỀ

Khi CLI trả report reports/s177-kb-protection-verify-20260414.md → em sẽ cập nhật vào đây.

Trạng thái hiện tại: ⏳ Chờ CLI chạy 5 câu C1-C5.

Khi có kết quả: patch §12.10 thêm bảng kết quả + 1 câu kết luận + quyết hướng A/B/C.

Living doc | Cập nhật khi có điều tra mới | Mỗi finding mới = 1 row trong §2 + cập nhật §1

§3. QUYẾT ĐỊNH KIẾN TRÚC CHỜ HUYÊN CHỐT

#	Câu hỏi	Đề xuất Desktop	Lý do
Q1	Bảng quản infra artifacts (A3) lưu thế nào?	Tạo collection mới `infra_artifacts` qua Directus API. Mỗi script/config/file hạ tầng = 1 row. Cột: code, type (script/config/profile), file_path, sha256, owner_dot, version, last_modified, registered_at, governance_role	Đúng PG-First (NT10), không vi phạm Đ35 (vì DOT chỉ cho data operation). Mở rộng tự nhiên cho mọi infra asset tương lai (nginx config, cron file, systemd unit...)
Q2	DOT-COL-CREATE có cover được QT-003 bước 3-4 không?	Đọc code `dot-collection-create` trên VPS để xác nhận. Nếu có → reuse. Nếu thiếu species-map hoặc birth-trigger-setup → phải tạo DOT bổ sung HOẶC patch DOT-COL-CREATE	Ưu tiên reuse trước khi sinh DOT mới (Đ7 Assembly First)
Q3	Drift `file_path` 100% (S164c metadata-shell) còn áp dụng không?	Em phải tự verify — Huyên không nhớ S164c. Probe git log + tracker S164c + đọc commit message để tìm ngữ cảnh gốc	Ảnh hưởng cách viết `file_path` cho 6 DOT mới Đ41
Q4	Trong ~200 DOT hiện có, DOT nào đã cover được QT-003 6 bước? Bao nhiêu DOT chưa khai sinh đầy đủ (chưa có birth_registry)?	Điều tra rộng theo domain+operation, không pattern tên. Sau đó áp dụng QT-001 backfill cho DOT chưa khai sinh trước khi sinh DOT mới	Tránh sinh DOT chồng chéo (Huyên S176B)

§4. TD MỚI PHÁT SINH (ngoài scope Đ41 nhưng cần ghi)

TD code	Nội dung	Ưu tiên	Block Đ41?
TD-LAW-00G-MISSING	Hiến pháp v4.5.1 reference `law-00g-birth.md` nhưng file KHÔNG TỒN TẠI trong KB. Đ4 `law-04-birth-process.md` chỉ 667 chars. Birth Registry nội dung đầy đủ có thể nằm ở `knowledge/dev/architecture/birth-registry-law.md` (S157) — phải verify và pull về `knowledge/dev/laws/` đúng chỗ	🟡 Medium	Không block Phase 1, nhưng phải fix trước khi tạo luật mới
TD-DIEU36-V4-MISSING	Đ36 v4.0 ENACTED (S155, "17 health checks, 67 domain rules") không có file riêng. Chỉ còn v5.0 DRAFT 30%. Rủi ro quên luật	🟡 Medium	Không block — Đ41 đủ ngữ cảnh từ Đ0-H + QT-003
TD-SPECIES-MAP-EMPTY	`species_collection_map` HOÀN TOÀN RỖNG (0 rows cho mọi species, kể cả SPE-COL/SPE-LAW/SPE-DOT đông collection). Cơ chế linkage species↔collection thực tế ở đâu?	🔴 High	Không block Phase 1 trực tiếp, nhưng bóp méo Đ29 — phải điều tra song song
TD-DOT-LAST-EXEC-NULL	`dot_tools.last_executed` = NULL cho 3 DOT-COL-* (và có thể nhiều DOT khác). Không thể chứng minh DOT đã chạy. Field deprecated hay DOT runtime không cập nhật?	🟡 Medium	Không block, nhưng D1-D6 phải tự cập nhật field này khi chạy
TD-DOT-FILEPATH-DRIFT	3 DOT-COL-* có drift 100% giữa registry path (`bin/dot/.ts`) và disk path (`/opt/incomex/dot/bin/` no extension). Đây là metadata-shell pattern S164c	🟢 Low	Không block — đã được Huyên chấp nhận trong S164c
TD-S164C-METADATA-SHELL-VERIFY	Verify pattern S164c (registry path ≠ disk path) là intentional design hay legacy bug. Tìm trong git log/handoff/tracker S164c để hiểu ngữ cảnh gốc. Huyên không nhớ → Desktop tự điều tra	🟡 Medium	Block 6 DOT mới Đ41 vì cần biết viết `file_path` thế nào cho đúng chuẩn
TD-DOT-COVERAGE-AUDIT	Điều tra TỔNG ~200 DOT theo domain+operation+file_path content (không pattern tên), liệt kê DOT nào đã cover QT-003 6 bước, DOT nào đã/chưa có khai sinh. Áp QT-001 backfill cho DOT chưa khai sinh trước khi sinh DOT mới Đ41.	🔴 High	DONE 2026-04-14 — kết quả: 272 DOT, 3 lớp registry pollution, operation 94% NULL, coverage complete chỉ 5%. Chuyển thành các TD con bên dưới
TD-DOT-REGISTRY-3-LAYER-DEDUPE	3 lớp registry song song (`DOT-XXX` số / `DOT_UPPER_SNAKE` / `DOT-COL-*` descriptive) cùng trỏ 3 file vật lý `dot-collection-{create,health,field-sync}`. Phải chốt 1 convention canonical, retire 2 lớp còn lại qua APR Đ35 §6 Luật Bảo toàn.	🔴 CRITICAL — block Đ41	Sinh DOT mới Đ41 vào pile này = thêm zombie. Phải dọn trước.
TD-DOT-OPERATION-94-NULL	`operation` field NULL cho 255/272 DOT (94%). Không thể query "DOT này làm gì" bằng metadata. Phải backfill operation cho toàn bộ 255 DOT theo file_path content + reference table `dot_operations`.	🔴 High	Block đo coverage thật. Block roadmap Đ35 MT2 "Đo được bằng số"
TD-DOT-HEALTH-DEAD	`dot-dot-health` (Đ35 §8.1, cảnh sát chính của DOT) suspect chưa chạy hoặc chạy nhưng không catch lỗi rõ: Lớp 3 file_path .ts SAI 100% mà không alert H4. 3 khả năng: cron chưa active / path resolve mềm / alert vào system_issues không ai đọc. Nếu cảnh sát chính ngủ → mọi metric coverage vô nghĩa.	🔴 CRITICAL — block toàn bộ Đ35 effectiveness	Pattern "self-healing-late" S176 KS.2 lặp lại
TD-S164BC-AUDIT-GAP	S164b/S164c tạo 10+ .bak files trên `/opt/incomex/dot/bin/` (birth, classification, schema, normative, doc, pivot...) nhưng KHÔNG trace được trong git history (clone VPS) hoặc KB markdown. Operation lớn chạy trực tiếp trên VPS không ghi sổ. Hỏi local git của Huyên (không phải clone VPS stale) hoặc trace mtime để dựng timeline.	🔴 High	Liên quan đến Đ41 NV1 — chính xác là pattern "sửa mã trên VPS không ghi sổ" mà Đ41 sinh ra để chặn
TD-DOT-COMPLETE-FAKE	Lớp 3 (`DOT-COL-CREATE`, `DOT-COL-HEALTH`, `DOT-COL-SYNC`) có `coverage_status='complete'` nhưng file_path `.ts` không tồn tại (file thật là bash). "Complete" được set trong DB mà không kiểm chứng disk. Vi phạm AP-CLOSE-VERIFY. Phải verify lại 13/272 DOT có coverage=complete xem có cái nào fake nữa không.	🟡 Medium	Block trust vào coverage_status
TD-DOT-244-ORPHAN	244 file trên `/opt/incomex/dot/bin/` không có row trong `dot_tools` — mồ côi đúng nghĩa Đ19 Side B. `dot-dot-health` Check 5 phát hiện đúng số 244 nhưng exit 0 → không ai biết. Phải register qua `dot-dot-register` auto scan + QT-001 backfill.	🔴 CRITICAL — NV1	Khoảng 33% file thật không có sổ
TD-DOT-ALERT-SUPPRESSION	`dot-dot-health` cron chạy daily, log phát hiện đúng 244 orphan + 60 NULL + 5 coverage gap, NHƯNG exit 0 → 0 row escalate vào `system_issues`. Đây là alert-suppression bug ở tầng escalation, không ở tầng detection. Fix: warnings → exit code != 0 HOẶC INSERT vào system_issues khi fail check.	🔴 CRITICAL P0 — BLOCKER tuyệt đối	Bước A của khai sinh toàn bộ. Không fix A → làm B-G xong cũng sẽ drift lại vô hình
TD-DOT-60-METADATA-SHELL	60/272 DOT có row trong dot_tools nhưng `file_path=NULL` — pattern S176 K2 đã phát hiện, chưa fix. Đề xuất `dot-file-path-orphan-check` tier-A (chưa tồn tại, phải sinh mới).	🔴 High	Backfill scope của bước C
TD-DOT-45-DUPLICATE-PAIR	45 cặp basename duplicate (L1_NUMBER ↔ L2_UPPER_SNAKE) trỏ cùng file vật lý dưới 2 convention tên khác nhau. 100% là cặp đôi, không có triple. Phải dedupe qua APR Đ35 §6 retire row cũ.	🔴 High	Bước D. Sau khi chốt convention canonical
TD-LAW-RETROFIT-CLAUSE	Gốc rễ kiến trúc sâu (Huyên chỉ 2026-04-14): Luật mới ban hành không kèm `retrofit clause` cho entity cũ → legacy mãi vênh. Đ35 v5.0 (S151) không có operation "khai sinh lại 272 DOT legacy" → 259/272 vẫn partial/NULL. Pattern sẽ lặp với Đ36/38/39/41. Phải bổ sung vào OR `operating-rules-law-drafting.md`: mọi luật mới PHẢI có §retrofit quy định cách áp cho entity hiện hữu.	🔴 CRITICAL — META LEVEL	Không block Phase 0, nhưng phải amend OR soạn luật để tránh lặp
TD-S176-DOT-ALERT-ESCALATION	Escalation path từ DOT warnings → system_issues → Telegram/Kuma chưa có. Cần thiết kế lại Đ22 Self-healing hoặc Đ35 §8 để mọi DOT check fail TỰ ĐỘNG INSERT system_issues.	🔴 High	Song song với TD-DOT-ALERT-SUPPRESSION
TD-S164BC-AUDIT-GAP	S164b/S164c tạo 10+ .bak files trên `/opt/incomex/dot/bin/` (birth, classification, schema, normative, doc, pivot...) nhưng KHÔNG trace được trong git history (clone VPS) hoặc KB markdown. Operation lớn chạy trực tiếp trên VPS không ghi sổ. Hỏi local git của Huyên (không phải clone VPS stale) hoặc trace mtime để dựng timeline.	🟢 DOWN Low	2026-04-14 update: G4 đã trace được — 56 files, window 13 phút 2026-04-04 02:39-02:52 UTC, original 10/10 còn tồn tại → backup-only safe operation. Chờ Huyên xác nhận ai chạy

§5. THỨ TỰ TRIỂN KHAI ĐÚNG LUẬT (sau khi gỡ blocker §3)

🔴 PHASE 0 — DỌN DỌT REGISTRY DOT (BLOCKER MỚI, 2026-04-14)
  Phát hiện sau audit: 3 lớp registry trùng lặp + cảnh sát ngủ + 94% operation NULL + Lớp 3 phantom.
  Sinh thêm DOT mới Đ41 vào pile = thêm rác metadata. PHẢI dọn trước.

  TERMINOLOGY (Đ0-B + Đ0-G + Đ19):
  - DOT = NGUYÊN TỬ Lớp 1 (atom). Sinh DOT mới = sinh atom mới của loài DOT đã có.
  - PHANTOM = sổ có row, thực tế không thấy file (Lớp 3 file_path .ts sai)
  - MỒ CÔI = file trên disk mà không có row trong dot_tools
  - KHAI SINH CHƯA ĐẦY ĐỦ = có row birth_registry nhưng metadata trong dot_tools partial/NULL
  - 272/272 DOT KHÔNG mồ côi (đều có row), KHÔNG phantom đại đa số (chỉ Lớp 3 phantom). 
    ĐÚNG bệnh: KHAI SINH CHƯA ĐẦY ĐỦ ở 95% + REGISTRY TRÙNG LẶP 3 lớp + PHANTOM Lớp 3.

  0.1. AUDIT CẢNH SÁT — verify dot-dot-health có chạy thật không
       - cron entry active?
       - last_executed cập nhật?
       - có alert vào system_issues khi file_path drift không?
       - nếu KHÔNG chạy → fix nó TRƯỚC mọi việc khác (cảnh sát ngủ = mọi metric vô nghĩa)

  0.2. MAP 3 LỚP REGISTRY TRÙNG LẶP — đối chiếu cụ thể:
       - liệt kê toàn bộ DOT trùng file vật lý qua nhiều convention (không chỉ 3 file collection-*)
       - timeline migration: lớp nào sinh khi nào (mtime + git log local Huyên)
       - quyết convention canonical (Lớp 3 DOT-COL-* descriptive là ứng viên hàng đầu vì có operation+trigger+coverage)

  0.3. RETIRE 2 LỚP CŨ qua APR (Đ35 §6 quy trình retire khép kín):
       - APR request_type='retire_dot' per row trùng
       - status='retired', coverage_status='deprecated'
       - cron disable (nếu có)
       - file vật lý GIỮ NGUYÊN (Luật Bảo toàn cấm xoá)
       - dot-dot-register skip retired (đã có logic này theo §8.3)

  0.4. BACKFILL METADATA cho lớp canonical (255 DOT operation NULL + 158 partial):
       - ĐÂY LÀ "KHAI LẠI" THEO NGHĨA HUYÊN — bổ sung metadata thiếu trong dot_tools
       - infer operation từ file_path content + naming convention
       - cập nhật reference table dot_operations qua APR ref_table_change nếu cần op mới
       - mục tiêu: 0 DOT có operation NULL, coverage_status='complete' cho mọi DOT đã verify
       - LƯU Ý: đây KHÔNG phải QT-001 backfill birth_registry (đã đầy đủ), mà là backfill metadata trong chính dot_tools

  0.5. AUDIT 13 DOT coverage=complete — verify file thực tế trên disk có khớp file_path không
       - Chạy DOT-DOT-HEALTH H4 thủ công nếu cron chưa chạy
       - Cái nào fake (như Lớp 3 .ts) → APR fix file_path hoặc retire

  0.6. VERIFY S164b/c: dựng timeline từ mtime .bak files (10+ files trên VPS)
       - find /opt/incomex -name "*.bak-s164*" -printf '%T+ %p\n' | sort
       - Đây cũng là use case đầu tiên cho Đ41 (sửa mã VPS không ghi sổ)
       - Hỏi local git Huyên (clone VPS stale, không có commit)

  → Sau Phase 0: cảnh sát thức + registry sạch + metadata đầy đủ. MỚI sang Phase 1A Đ41.

PHASE 1A.0 — ĐIỀU TRA DOT HIỆN HỮU (BƯỚC 0 BẮT BUỘC, Huyên S176B)
  ✅ DONE 2026-04-14 — kết quả: 3 DOT khai sinh QT-003 ĐỀU TỒN TẠI.
  - DOT-119 birth-trigger-setup (cấp collection, dùng fn_birth_registry_auto, đã setup cho 133 collection)
  - DOT-120 collection-register
  - DOT-145 species-map
  - dot-collection-create v2.0.0 (Lớp 3 DOT-COL-CREATE) đã có Step 17 species + Step 18 birth trigger native
  → KHÔNG cần sinh sub-DOT khai sinh mới. Reuse `dot-collection-create` cho A1+A2 sau khi Phase 0 xong.

PHASE 1A — Mở rộng luật + tạo công cụ thiếu THẬT (sau Phase 0 + 1A.0)
  1. Quyết Q1, Q2, Q3 (§3)
  2. (Nếu Q1=A) Tạo bảng infra_artifacts qua DOT-COL-CREATE
  3. (Nếu Q2 thiếu) Tạo DOT bổ sung (DOT-SPECIES-MAP, DOT-BIRTH-TRIGGER-SETUP) qua Đ35 §5 8 bước

PHASE 1B — Tạo 2 collection chính
  4. DOT-COL-CREATE → POST /collections vps_deploy_log (15 cột Đ41 §8)
     - governance_role='observed', species=SPE-LOG, purpose=...
     - birth trigger auto
  5. DOT-COL-CREATE → POST /collections smoke_profiles
     - governance_role='governed', species=SPE-GOV, purpose=...
  6. Verify fn_registry_health() bắt 2 collection mới

PHASE 1C — Sinh 6 DOT cảnh sát (Đ35 §5 8 bước × 6)
  7-12. APR new_dot × 6 → file .ts → dot-dot-register → birth → health baseline

PHASE 1D — Filesystem + scripts
  13. Tạo 5 thư mục theo Đ41 §2 (qua DOT/script chuẩn)
  14. Snapshot mã hiện tại → release legacy đầu tiên
  15. Symlink current
  16. Move .env.production về /opt/incomex/secrets/ (chmod 600)
  17. Viết app-deploy.sh + infra-deploy.sh + đăng ký vào infra_artifacts
  18. Seed 3 row smoke_profiles (nuxt, directus, agent-data)

PHASE 1E — Kích hoạt
  19. Bật cron 5 DOT cron-triggered
  20. dot-dot-health baseline → 0 critical
  21. Ghi sổ tay vps_deploy_log dòng đầu tiên (snapshot legacy)

§6. CHANGELOG

Ver	Ngày	Nội dung
v0.11	2026-04-14 S177 Fix 8 ĐÊM	Đ35 v5.1 FINAL BAN HÀNH. Council 2 vòng DONE (R1 fix 5 blocker, R2 apply 7 minor inline). +§2 entries #26/#27/#28 ghi nhận R1/R2/ban hành. §13.5 REWRITE thành 14 TODO triển khai thực tế. §1.1 update bản chất blocker sau v5.1. Pha mới: TỪ "viết luật" → "triển khai luật trên VPS".
v0.10	2026-04-14 S177 Fix 8 TỐI	+§13 BỨC TRANH FINAL SAU CLI V2+V3. 4 RC đóng. 280 warning collection_onboarding_gap ≠ 272 DOT Đ35 vô hình. Gap-5 đóng cứng (KB Protection Phase 1+2 LIVE). TD-KB-OWNER-DRIFT mới. Hoạch định v5.1 draft.
v0.9	2026-04-14 S177 Fix 7	§12 KB Protection verify + 2 cơ chế Phase 1 Phase 2. §11 gốc 5 tầng + Điều 42 candidate (sau bỏ). §10 3 câu trả lời khung + PROMPT-LAW DRIFT + AP-22.
v0.8	2026-04-14 S177 chiều	+3 entries §2 (#11 CLI report, #12 49 DOT POST-S151, #13 mâu thuẫn KB↔VPS). +§1.1 cập nhật bảng artifact: blocker thực sự là bệnh TẦNG LUẬT không phải thiếu công cụ. Phase 1 LÙI sau Phase -1 chữa Đ35 nền tảng.
v0.7	2026-04-14 S177	+§8 Áp 4-câu-hỏi-khung vào bệnh 272 DOT. Đọc full Đ35 v5.0 → phát hiện 4 LAW GAP (nullable hợp pháp / health thiếu H10-H11 / grace không enforce / retrofit thiếu) + 4 khoảng trống liên luật. Liệt kê 10 câu hỏi CLI còn treo. Kết luận: chưa đủ luật để backfill — phải AMEND Đ35 v5.0 → v5.1 trước. Nguyên tắc Huyên chốt memory #15: mọi quyết định phải đọc lại luật, chưa có luật = đề xuất bổ sung, không sáng tác.
v0.6	2026-04-14	+§7 WHY phân tích gốc rễ 7 lỗi S176B, 5 root cause, AP-VOI-PHAN-HOI, 5-gate check trước mọi đề xuất. Bài học Huyên: "Tìm lỗi là đúng, không hiểu tại sao thì mai lại lỗi tiếp"
v0.5	2026-04-14	+Phase 0 chi tiết với terminology đúng (mồ côi/phantom/khai sinh chưa đầy đủ), entries #6 #7 vào §2
v0.4	2026-04-14	CRISIS audit DOT — 3 lớp registry trùng, cảnh sát suspect ngủ, 5 TD mới
v0.3	2026-04-14	Phase 1A.0 điều tra DOT trước khi sinh mới (Huyên cảnh báo)
v0.2	2026-04-14	+Q4 audit ~200 DOT, +TD-S164C-METADATA-SHELL
v0.1	2026-04-14	Tạo phụ lục. Bảng tổng 22 artifact, kết quả CLI Q1-Q5, 5 TD mới, 21 bước triển khai, 3 quyết định chờ chốt

§7. WHY 7 LỖI S176B — PHÂN TÍCH GỐC RỄ (2026-04-14)

Bài học gốc Huyên (Memory #5): "Mỗi lỗi tìm thấy = cơ hội học gốc rễ. Không vá triệu chứng. Phải đặt câu hỏi WHY và trả lời bằng evidence cứng trước khi thiết kế giải pháp."

"Tìm lỗi là đúng, nhưng không hiểu tại sao lỗi thì mai lại lỗi tiếp." (Huyên 2026-04-14)

Bảng 7 lỗi → WHY → Root cause

#	Hiện tượng (lỗi)	WHY 1 (lý do bề mặt)	WHY 2 (gốc nhận thức)	Root cause
1	Đề xuất `DOT-SCHEMA-*-ENSURE` qua psql DDL trực tiếp tạo collection	Em thấy Đ33 §13 E1 có ngoại lệ "Schema bootstrap DDL" → áp dụng	Em đọc tên ngoại lệ mà bỏ qua điều kiện áp dụng: E1 chỉ cho schema core mà Directus REST không expose. `vps_deploy_log` là business collection, Directus thừa sức quản	R1 — ĐỌC TỪ KHÓA, KHÔNG ĐỌC NGỮ CẢNH ÁP DỤNG
2	Đề xuất ghi metadata script vào file markdown `vps-contabo.md`	Em thấy file đó tồn tại → tưởng pattern OK	Em không hỏi "file này có đúng luật không?". Coi "có sẵn" = "hợp luật"	R2 — DÙNG "CÓ SẴN" LÀM BẰNG CHỨNG ĐÚNG LUẬT
3	Đề xuất smoke profile YAML file trên disk	Đ41 §7 nói "có thể ở dạng YAML/JSON"	Em đọc 1 câu trong 1 luật mà không đối chiếu với HP NT10 (PG-First) + Đ7 Assembly First + Đ0-H 5-tầng. 1 câu trong luật con không override hiến pháp	R3 — ĐỌC LUẬT RIÊNG LẺ, KHÔNG ĐỌC HỆ THỐNG LUẬT CHÉO NHAU
4	Probe DOT bằng pattern tên hẹp `%species-map%` → kết luận "thiếu"	Em copy tên DOT từ QT-003 làm pattern, không nghĩ đến việc registry đặt tên khác	Em không đo kích thước hệ thống (272 DOT, đa convention) trước khi probe. Tìm cây kim mà không biết rừng to bao nhiêu, không biết kim có nhiều dạng	R4 — PROBE TRƯỚC KHI ĐO KÍCH THƯỚC
5	Hỏi Huyên về S164c (anh không nhớ)	Em nghĩ user có ngữ cảnh em không có	Em không tìm trong KB + git log + filesystem TRƯỚC khi hỏi. Coi user là cache — sai. User là người ra quyết định, KB+git+disk là cache	R5 — COI USER LÀ CACHE (vi phạm Memory: "không hỏi multiple choice — tự quyết")
6	Sáng tác từ "zombie" thay vì dùng từ chuẩn (phantom / khai sinh chưa đầy đủ)	Em thấy hiện tượng, không có từ chuẩn trong đầu → tự đặt	Em không search vector tìm từ chuẩn trước khi viết. Vội phản hồi → sáng tác khi không biết = ô nhiễm thuật ngữ hệ thống	R6 — VỘI PHẢN HỒI: SÁNG TÁC KHI KHÔNG BIẾT
7	Hiểu sai QT-002 ("khai trước sinh sau" = entity loài mới)	Em đọc QT-002 rời rạc trong `birth-procedures.md`	Em không đọc Đ0-B v3.1 (DOT=atom Lớp 1) + Đ29 (species) trước. Cùng pattern R3 — đọc luật rời rạc	R3 lặp lại

5 ROOT CAUSE TỔNG + cách diệt

RC	Tên	Cách diệt vĩnh viễn
R1	Đọc từ khóa, không đọc ngữ cảnh áp dụng	Mỗi khi thấy ngoại lệ/exception trong luật → đọc ĐỦ điều kiện áp dụng + ngoại lệ của ngoại lệ trước khi quyết áp dụng
R2	Dùng "có sẵn" làm bằng chứng đúng luật	Mỗi artifact hiện có phải verify "tuân luật nào, ban hành phiên nào, có TD/AP nào liên quan" trước khi reuse
R3	Đọc luật rời rạc	Mỗi đề xuất phải đối chiếu tối thiểu 3 luật chéo: HP NT + luật chính + luật phụ trợ. 1 câu luật con không override HP
R4	Probe trước khi đo kích thước	`SELECT COUNT(*) + COUNT(DISTINCT pattern)` TRƯỚC `SELECT WHERE pattern LIKE`. Đo to nhỏ trước khi tìm cụ thể
R5	Coi user là cache (sai)	User = người ra quyết định. Cache = KB + git + filesystem. Trước khi hỏi user → search vector + đọc luật + probe filesystem. Chỉ hỏi user khi cần quyết định kiến trúc
R6	Vội phản hồi: sáng tác khi không biết	Im lặng > sáng tác. Không tìm thấy từ chuẩn → search lại, search rộng hơn, đọc luật. KHÔNG bao giờ tự đặt thuật ngữ ngoài luật

ANTI-PATTERN GỐC chung — `AP-VOI-PHAN-HOI`

Pattern: Phản hồi nhanh > phản hồi đúng. Trade-off sai trong context Incomex.

Vi phạm:

HP NT9 "Không chắc đúng = SAI. Không chắc → DỪNG + verify"
HP NT2 "Tự động 100%" — phản hồi nhanh-mà-sai → người dùng phải sửa thủ công → phá tự động
Memory #1 "Nghĩ kỹ, nghĩ sâu, đọc thông tin đầy đủ, phản hồi ngắn gọn" — em đã làm ngược: phản hồi nhanh, không nghĩ kỹ

Hệ quả: Mỗi sai = 5-15 phút Huyên phải sửa = mất tiền + mất ngữ cảnh + mất niềm tin.

5-GATE CHECK BẮT BUỘC trước mọi đề xuất mới

Gate	Câu hỏi	Nếu fail
G1	Luật nào chi phối? Đã đọc ĐỦ điều kiện áp dụng + ngoại lệ chưa?	DỪNG, đọc đủ
G2	Hệ thống đã có gì? Đã `COUNT + DISTINCT` để đo kích thước chưa? Đã search vector chưa?	DỪNG, search rộng
G3	Có vi phạm HP NT nào không? Đã đối chiếu tối thiểu 3 luật chéo chưa?	DỪNG, đối chiếu
G4	Từ chuẩn của hiện tượng này là gì? Có trong luật/KB không?	KHÔNG có → DỪNG, im lặng, search lại. KHÔNG sáng tác
G5	Mình CÓ CHẮC không?	KHÔNG chắc → DỪNG, search tiếp. KHÔNG hỏi user việc có thể tự tìm

Bài học vĩnh viễn

Vội = mai làm lại. Trong Incomex, mỗi quyết định sai phá nhiều thứ hơn em tưởng vì hệ thống được xây để tự động. Tự động trên dữ liệu sai = tự động sai nhanh hơn. Vì vậy "Không chắc đúng = SAI" không phải lời khuyên — là điều kiện sống còn của tự động hoá.

§8. ÁP 4-CÂU-HỎI-KHUNG VÀO BỆNH 272 DOT VÊNH METADATA (2026-04-14, S177)

Nguyên tắc Huyên chốt 2026-04-14 (đã ghi memory #15): Mọi điều tra chỉ loanh quanh 4 câu hỏi. Không lan man. 4 câu khung: (1) Đã có luật chưa? (2) Luật đủ chưa? (3) Thực tế đã theo luật chưa? (4) Luật có xung đột luật khác không?

§8.1 — Bệnh cần chẩn: 272 DOT, 94% `operation=NULL`, 3 lớp registry trùng, Lớp 3 phantom, 244 mồ côi, cảnh sát câm

§8.2 — Q1: ĐÃ CÓ LUẬT CHƯA?

✅ CÓ. Điều 35 v5.0 FINAL (ban hành S151, 2026-03-31) quản trị DOT. Tuân thủ HP v4.4.0 + Đ0-G + Đ32.

Tóm luật Đ35 liên quan:

§4.1 schema dot_tools 10 fields
§5 quy trình 8 bước tạo DOT mới
§8 3 DOT cặp tự quản trị (health + coverage + register)
§8.1 9 health checks H1-H9
§9 bootstrap + grace period
§10 Success Metrics

§8.3 — Q2: LUẬT QUY ĐỊNH ĐỦ CHƯA?

⚠️ KHÔNG ĐỦ. Em đọc full Đ35 v5.0 và thấy 4 LAW GAP cụ thể:

Lỗ hổng	Điều khoản	Hệ quả thực tế
GAP-1: Nullable hợp pháp	§4.1 `operation` FK nullable, `file_path` nullable, `coverage_status` FK nullable, `last_executed` nullable	Luật CHO PHÉP row tồn tại với metadata rỗng. 94% operation NULL KHÔNG vi phạm §4.1 — luật không chặn
GAP-2: Health check thiếu	§8.1 có H1 (`domain='unclassified'`) + H4 (`file_path` không tồn tại) nhưng KHÔNG có H10 `operation IS NULL` + KHÔNG có H11 `coverage_status IS NULL` sau grace	255/272 DOT NULL operation không tạo APR nào
GAP-3: Enforce gate hết grace	§9.3 quy định grace period "WARNING thay vì CRITICAL" nhưng không định nghĩa sau grace thì block/retire/escalate thế nào	Hết grace mà không enforce = grace mãi mãi = luật chết
GAP-4: Retrofit clause HOÀN TOÀN THIẾU	Đ35 v5.0 ban hành S151 nhưng không có §retrofit cho 272 DOT legacy tạo trước S151. Chỉ có §9 Bootstrap (1 lần tạo schema, không cho entity legacy)	Legacy mãi vênh luật. Anh đã chỉ ra 2026-04-14 trong entry #9 §2

Phụ lục liên quan — ứng viên thêm chặt:

§4.1 cần UNIQUE(file_path) WHERE file_path IS NOT NULL + CHECK(code không trùng semantic qua convention) để chặn 3 lớp registry trùng
§10 Success Metrics cần thêm "100% DOT active có operation NOT NULL, coverage_status='complete' sau grace"
§5 bước 4 cần chi tiết hóa "register với metadata đầy đủ" — hiện chỉ nói "FK enforce"

§8.4 — Q3: THỰC TẾ ĐÃ LÀM THEO LUẬT CHƯA?

⚠️ MỘT PHẦN — vi phạm §8.1 + tinh thần MT1/MT2/MT3:

Hiện tượng	Vi phạm điều nào	Bằng chứng
94% operation NULL	KHÔNG vi phạm §4.1 (nullable hợp pháp) nhưng vi phạm tinh thần MT1 ("nhìn toàn cảnh = biết mọi DOT làm gì") + MT2 ("đo bằng số")	G1-G4 audit CLI 2026-04-14
3 lớp registry trùng (45 cặp)	KHÔNG vi phạm constraint (không có UNIQUE) nhưng vi phạm §2 "SSOT duy nhất"	Entry #4 §2
Lớp 3 file_path .ts drift 100%	VI PHẠM §8.1 H4 (file_path không tồn tại → phải APR)	Entry #4 §2
244 file mồ côi	VI PHẠM §8.1 H7 (file disk không trong registry → phải APR)	Entry #8 §2
`dot-dot-health` exit 0 không escalate	VI PHẠM §8.3 NT2 "Tự động 100%" + tinh thần MT3 "khép kín"	Entry #8 §2: cron daily chạy, detect đúng, exit 0, 0 row escalate

Phát hiện cốt lõi: Đa số "bệnh" KHÔNG phải vi phạm luật trực tiếp — là lỗ hổng ở tầng constraint + tầng enforce. Luật viết đủ tầm nhìn (MT1-MT3) nhưng thiếu công cụ enforce ở tầng PG/health. Đây chính là pattern "luật có tầm, cơ chế câm".

§8.5 — Q4: LUẬT CÓ XUNG ĐỘT VỚI LUẬT KHÁC KHÔNG?

⚠️ KHÔNG xung đột trực tiếp, có KHOẢNG TRỐNG LIÊN LUẬT:

Khoảng trống	Luật A	Luật B	Trống ở đâu
LG-1: Ai backfill metadata dot_tools?	Đ35 §5 bước 4 (register)	Đ0-G QT-001 (backfill birth_registry)	QT-001 chỉ nhập birth row, KHÔNG nhập operation/file_path vào dot_tools. Không luật nào nói "ai backfill metadata dot_tools legacy"
LG-2: Retrofit legacy khi luật mới	Đ35 v5.0 (S151)	OR `operating-rules-law-drafting.md`	OR soạn luật không yêu cầu luật mới PHẢI có §retrofit. Sẽ lặp với Đ36/38/39/41 — anh chỉ 2026-04-14
LG-3: Alert escalation path	Đ35 §8.1 health detect	Đ22 Self-healing (chưa verify)	health detect đúng 244+60+5 nhưng không có đường INSERT vào `system_issues` → Telegram → con người. Câu 3 CLI sẽ verify Đ22
LG-4: UNIQUE file_path	Đ35 §4.1 schema	Đ33 PG §13 (constraint)	Cả hai không quy định ngăn 2 DOT cùng trỏ 1 file vật lý. 45 cặp duplicate hợp pháp về mặt constraint

§8.6 — CÂU HỎI CÒN TREO CLI PHẢI TRẢ LỜI (10 câu)

Desktop đã chẩn qua KB đủ cho 4 câu khung. Còn lại phải verify trên VPS (code source + schema thực tế + runtime state):

#	Câu hỏi	Trả lời câu khung nào	Method
C1	Schema `dot_tools` THỰC TẾ trên VPS có khớp §4.1 luật không? Có NOT NULL nào luật không viết nhưng schema có?	Q2 (xác nhận lỗ hổng nullable)	`\d+ dot_tools` + `SELECT * FROM pg_constraint`
C2	Code `dot-dot-health` — H1 và H4 đã implement trong source chưa? Nếu detect thì code xử lý thế nào (exit 0 hay INSERT system_issues)?	Q3 (vi phạm §8.1)	đọc `/opt/incomex/dot/bin/dot-dot-health`
C3	Code `dot-dot-register` — khi register DOT mới có infer operation/coverage_status từ naming convention theo §9.2 block 2 không, hay chỉ tạo row với 2 field bắt buộc?	Q3 (công cụ thiếu bước) + Q2 (luật §5 bước 4 chưa chi tiết)	đọc source
C4	Code `dot-collection-create` v2.0.0 — Step 17 (species) + Step 18 (birth trigger) có nhánh backfill metadata `dot_tools` cho DOT mới không, hay chỉ tạo collection?	Q3 (reuse được không)	đọc source
C5	`dot_config.grace_period_days` value hiện tại = bao nhiêu? DOT-272 tạo lúc nào? Đã hết grace chưa?	Q2/Q3 (§9.3 grace enforce)	`SELECT value FROM dot_config WHERE key='grace_period_days'` + `SELECT MIN(created_at) FROM dot_tools`
C6	`dot_operations` reference table có bao nhiêu code? Cover hết file DOT trên disk không? Nếu thiếu operation mới thì APR `ref_table_change` có được dùng bao giờ chưa?	Q3 (có đủ vocabulary để backfill không)	`SELECT * FROM dot_operations`
C7	APR tracker — có APR nào từng được tạo cho `classify_unclassified` / `fix_file_path_drift` / `register_orphan` / `backfill_operation` KHÔNG? Nếu có bao nhiêu pending/executed/rejected?	Q3 (chứng minh chain enforce có chạy)	`SELECT request_type, status, count(*) FROM apr GROUP BY 1,2`
C8	Điều 22 Self-healing — có quy định "health fail → INSERT system_issues" không? Có trigger/DOT bắc cầu từ health output → system_issues không?	Q4 LG-3 (escalation path)	`get_document knowledge/dev/laws/dieu22-*` + `grep system_issues /opt/incomex/dot/bin/dot-dot-health`
C9	Điều 0-G Birth Registry law — file chính nằm ở path nào? Có quy định backfill metadata NGOÀI birth_registry không? (TD-LAW-00G-MISSING)	Q4 LG-1 (ai backfill metadata)	`list_documents knowledge/dev/laws/` + grep "law-00g"
C10	Timeline 272 DOT — mtime/created_at phân bố thế nào? Có cluster "trước S151 v5.0" vs "sau S151" không? Bao nhiêu DOT được tạo theo §5 8 bước chuẩn (sau S151) vs bao nhiêu legacy?	Q4 LG-2 (retrofit clause)	`SELECT date_trunc('month',created_at), count(*) FROM dot_tools GROUP BY 1`

§8.7 — KẾT LUẬN CHẨN ĐOÁN (trước khi CLI chạy)

Đủ luật để bắt đầu? ⛔ CHƯA. Có lỗ hổng GAP-1 đến GAP-4 cần AMEND Đ35 trước khi backfill 272 DOT.
Đủ luật để amend? ⛔ CHƯA. Phải verify 10 câu CLI trước để biết amend chỗ nào cho chính xác.
Phase 0 dọn registry được bắt đầu chưa? ⛔ CHƯA. Phase 0 phụ thuộc §retrofit clause + health check mở rộng.
Hành động kế: CLI điều tra 10 câu → Desktop phản biện → soạn AMEND Đ35 v5.0 → v5.1 (Council nếu cần) → ban hành v5.1 → MỚI triển khai Phase 0 theo luật mới.

§9. BÁO CÁO CLI S177 — LAW GAP VERIFY (2026-04-14)

Nguồn: reports/s177-dieu41-law-gap-verify-20260414.md (~17KB) — Claude Code CLI thực thi 10 câu C1-C10 + verify schema/code/runtime/timeline trên VPS thật.

§9.1 — Kết quả 10 câu (mỗi dòng = 1 câu, có cờ mức độ)

C#	Phát hiện	Mức
C1 Schema `dot_tools` thực	4/5 fields Đ35 §4.1 yêu cầu FK lại dùng CHECK hardcoded array (vi phạm NT4 — Sẵn sàng thay đổi). `operation` KHÔNG có cả CHECK lẫn FK (hợp pháp NULL). 18 cột legacy ngoài luật. Domain đúng FK. 2 trigger birth duplicate (`birth_trigger_dot_tools` + `trg_birth_dot_tools` — gọi 2 lần per INSERT)	🔴
C2 `dot-dot-health` code	H1 + H4 implement đúng luật, CÓ gọi `log_system_issue` source='dot-dot-health'. Bệnh: dùng `curl ... \|\| true` silent-fail → 0 row vào `system_issues` thật. Cảnh sát có miệng nhưng nuốt báo cáo	🟡
C3 `dot-dot-register` ROOT-CAUSE	Engine register chỉ set 6/10 fields, KHÔNG set `operation`/`coverage_status`/`trigger_type`/`last_executed`. Hardcode `paired_dot=DOT-HEALTH-DOT`. Emit Lớp 2 UPPER_SNAKE + flat domain không match dotted seed §4.2. Đây chính là engine đẻ ra 94% NULL operation + 3 lớp registry trùng + vocabulary mismatch.	🔴
C4 `dot-collection-create`	Step 17/18 chỉ lo `collection_registry` + `species_collection_map` + delegate `dot-birth-trigger-setup`. 0 hit trên `dot_tools` → KHÔNG thể reuse cho backfill metadata DOT	⚪ out-of-scope
C5 Bootstrap chưa xong	`dot_config` + 4 reference tables (`dot_tiers`, `dot_operations`, `dot_trigger_types`, `dot_coverage_statuses`) KHÔNG TỒN TẠI trên VPS thật → §9.2 BLOCK 1 chưa chạy → grace_period_days vô định → enforce gate không thể kích hoạt. ⚠️ MÂU THUẪN với KB (xem §9.3 dưới)	🔴
C6 `dot_operations` thực	Table không tồn tại (khớp C5). Thực tế DOT dùng 12 op values: 8/12 ngoài luật seed (`verify`, `delete`, `update`, `restore`, `import`, `snapshot+audit`, `seed`, `partial`). 4 luật seed (`sync`, `ensure`, `execute`, `classify`) không ai dùng	🔴
C7 APR	Bảng tên thực `approval_requests` (không phải `apr`). Chỉ 4 request_types toàn hệ: `accuracy_drift`, `birth_orphan`, `reclassify` (+1 nữa). 32 APR cho `dot_tools`, 0 từ `dot-dot-health`. Luật §8.1 nói APR, code dùng `system_issues` — 2 kênh không bridge	🟡
C8 Đ22 luật	Luật rõ "DOT → system_issues → UI" (KB id=922 line 11/39/53). Code `dot-dot-health` có thử. Runtime câm cùng C2. Thiếu chuỗi cấp 2: system_issues → APR → Telegram	🟡
C9 Đ0-G luật	TỒN TẠI (KB id=737) nhưng slug `dev-architecture-birth-registry-law` (đặt nhầm folder, đáng lý `dev-laws-`). LG-1 (ai backfill metadata `dot_tools` legacy) vẫn là khoảng trống thật	🟡
C10 Timeline 272 DOT	108 NULL `date_created` + 115 created tháng 3/2026 + 49 tháng 4/2026. 49 DOT POST-S151 vẫn 94% NULL operation. → ★★★ Vấn đề KHÔNG phải retrofit cho legacy mà engine §5 bước 4 không tuân §4.1 → retrofit phải áp luôn cho cả DOT mới	🔴

§9.2 — 3 LG MỚI (ngoài 4 LG §8.5)

LG mới	Mô tả	Hậu quả
LG-5 Trigger duplicate	`birth_trigger_dot_tools` + `trg_birth_dot_tools` cùng trỏ 1 bảng → mỗi INSERT chạy 2 lần	Có thể đẻ duplicate row birth_registry. Cần verify side-effect
LG-6 Reference tables missing	§9.2 BLOCK 1 dở dang trên VPS thật	Toàn bộ §4 schema + §5 quy trình + §8.1 health checks không có nền tảng để enforce. Luật chết từ ngày sinh
LG-7 Vocabulary mismatch	Engine emit flat domain ('infrastructure') không match dotted seed ('infrastructure.deploy') §4.2. 12 op values thực ngoài 9 op luật seed	67% operation values là sáng tác runtime, không ai approve. Naming entropy tăng theo thời gian

§9.3 — ⚠️ MÂU THUẪN KB ↔ VPS RUNTIME (PHÁT HIỆN GỐC SÂU NHẤT)

KB phát biểu (vector search 2026-04-14):

"S155 DOT bootstrap cho Đ35 và Đ36 ĐÃ HOÀN THÀNH. 4 SSOT tables, 6 DOT scripts, 3 cron jobs, PR #655 merged. Đ35 và Đ36 chuyển từ 'issued on paper' sang active production với 4 lớp bảo vệ."

VPS runtime evidence (CLI psql trực tiếp 2026-04-14):

"dot_config + dot_tiers + dot_operations + dot_trigger_types + dot_coverage_statuses KHÔNG TỒN TẠI trong DB directus."

→ Hai sự thật mâu thuẫn nhau. Đây CHÍNH XÁC là pattern metadata-shell S176 KS.3: sổ ghi DONE, thực tế trống. Pattern lặp ở mức luật → vô cùng nghiêm trọng vì mọi quyết định kiến trúc trong 1.5 tháng qua dựa trên giả định "Đ35 active production".

3 khả năng cần verify:

PR #655 merged code nhưng migration runner không chạy (silent fail trong CI/CD)
Migration chạy nhưng rollback (S164 .bak files có liên quan?)
PR #655 chỉ merge code DOT scripts, KHÔNG kèm migration SQL

Cần CLI 1 cú verify ngắn (3 lệnh):

psql -d directus -c "\dt dot_*"
psql -d directus -c "\dt approval*"  
ssh vps "find /opt/incomex -name '*.sql' -path '*dot*' -mtime -60 | head -20"
git -C /mnt/kb-clone log --oneline --all | grep -i "655\|dot.*bootstrap" | head -10

→ Trả lời 1 câu duy nhất: PR #655 thực sự làm gì trên VPS? Sau đó mới quyết hướng amend.

§9.4 — ⚠️ SUPERSEDED by §13.5 (2026-04-14 S177 Fix 8)

Section này lỗi thời. Các câu hỏi "bệnh gì, có amend luật không" đã được trả lời: v5.1 FINAL BAN HÀNH 2026-04-14. Xem §13.5 — 14 TODO triển khai cho kế hoạch hiện hành.

~~Nội dung §9.4 cũ (giữ để audit lịch sử điều tra Fix 7):~~

KHÔNG soạn AMEND Đ35 v5.0 → v5.1 ngay. Lý do: nếu vấn đề là "luật đúng nhưng bootstrap chưa chạy" thì amend luật vô nghĩa — phải chạy bootstrap trước. Nếu vấn đề là "luật thiếu + bootstrap cũng chưa" thì amend phải bao gồm cả §retrofit cho 49 DOT post-S151.

(§9.4 trước Fix 8: đang chờ verify. Sau Fix 8: đã amend xong v5.1, chuyển sang giai đoạn triển khai §13.5.)

§13. BỨC TRANH FINAL SAU CLI V2+V3 (2026-04-14 S177 Fix 7 đêm)

Nguồn: Báo cáo reports/s177-kb-protection-verify-20260414.md (CLI V1 đêm Fix 7) + reports/s177-finish-rc34-20260414.md (CLI V3). Đóng toàn bộ điều tra 4 RC.

§13.1 — Bài học lớn của Desktop

Sai	Gốc	Memory đã ghi
Soạn prompt `ssh vps` (alias không có)	Hardcode từ conversation_search ký ức sai	#18 cập nhật: alias = `contabo`
Soạn prompt `-d directus` cho KB Protection	Hardcode db name, không verify	#18 cập nhật: KB ở `incomex_metadata`, DOT/APR ở `directus`. PRECHECK phải `\l` list db
Soạn prompt `last_exec_at` (cột thực là `last_executed`)	Sáng tác tên column	Bao hàm trong G4 5-GATE

Pattern chung: AP-VOI-PHAN-HOI vi phạm NT9 — giả định từ ký ức, không verify. Đã 3 lần trong 1 phiên. Phải thực thi 5-GATE G4 nghiêm khắc hơn.

§13.2 — Bức tranh 4 RC FINAL (thay thế §2 entry #11 "4 Root Cause")

RC	Gốc cứng (sau CLI V2+V3)	Công cụ fix đã có?
RC-1	`fn_birth_gate` mode=warning (không block), BEFORE INSERT FOR EACH ROW chỉ soi row MỚI, KHÔNG scan ngược 272 DOT cũ	✅ `DOT_BIRTH_BACKFILL` tồn tại nhưng `last_executed=NULL` — chưa chạy lần nào
RC-2	`dot_tools` 4/5 fields §4.1 dùng CHECK hardcode thay vì FK (vi phạm NT4). `operation` không CHECK không FK → nullable hợp pháp. Thiếu UNIQUE(file_path) + NOT NULL	❌ Phải amend Đ35 v5.0 → v5.1
RC-3	2 lớp: (a) 280 warning OPEN tháng 4, cũ nhất 20 ngày, 0 handler đọc (`dot-collection-health` detect → ghi `system_issues` ✅ nhưng không DOT nào đọc xử lý). (b) 272 DOT Đ35 KHÔNG có DOT scan nào — không metadata completeness scanner → Đ35 bệnh VÔ HÌNH trong `system_issues`	❌ Phải build DOT scan metadata + handler reading system_issues
RC-4	Công cụ thật là `/opt/incomex/dot/bin/dot-dot-register` (193 dòng) POST `/items/dot_tools`. Payload thiếu 5 cột: operation, coverage_status, trigger_type, cron_schedule, _dot_origin. Lưới đỡ `[AUTO-ID] DOT Tools` Directus flow INACTIVE	✅ Flow có sẵn, chỉ cần BẬT + vá `dot-dot-register` bổ sung 5 cột (làm cả 2 để dual-trigger)

§13.3 — 280 WARNING KHÔNG PHẢI 272 DOT Đ35 (BẤT NGỜ)

Toàn bộ 280 warning = collection_onboarding_gap "Species code missing: " cho ~28 bảng (10 rows/bảng tích lũy)
Source: dot-collection-health
Cũ nhất 20 ngày 4h
272 DOT Đ35 KHÔNG xuất hiện trong system_issues — không scan nào bắn vào

→ Hệ thống đang mắc 2 bệnh độc lập:

Bệnh có cảnh báo nhưng không ai đọc (280 species_missing — cần handler)
Bệnh không có cảnh báo nào bắn (272 DOT Đ35 — cần scanner mới)

§13.4 — Gap-5 đóng cứng, Gap-8 WARN≠BLOCK xác nhận

KB Protection Phase 1 + Phase 2: ✅ LIVE ở incomex_metadata (CLI V1 verify 4/4 mechanism: 6/6 trigger enabled, history 10,577 rows/1933 docs, updated_at age 44s, cron 2026-04-13 21:00 green)
TD mới: TD-KB-OWNER-DRIFT — 3 bảng kb_documents/_history/audit_log owner = incomex thay vì workflow_admin như intent S170. Runtime vẫn an toàn nhờ SECDEF + revoke grants. Fix: 1 lệnh ALTER TABLE ... OWNER TO workflow_admin
Gap-8 WARN≠BLOCK: vẫn treo, CLI chưa đếm tổng truncation_warning tháng 4. Biện pháp: đổi fn_birth_gate + fn_kb_truncation_guard từ warning → block hoặc warning + auto-INSERT system_issues + APR

§13.5 — KẾ HOẠCH TRIỂN KHAI (CẬP NHẬT 2026-04-14 S177 Fix 8 — POST BAN HÀNH v5.1)

★ Status Update: Bước 1-3 trên giấy (amend luật + OR + AP) đã DONE. Chuyển sang giai đoạn triển khai thực tế trên VPS.

Checkpoints đã đạt:

#	Việc	Trạng thái	Evidence
1	Amend Đ35 v5.0 → v5.1	✅ DONE	`dieu35-dot-governance-law.md` rev 2 (v5.1 FINAL)
2	Council 2 vòng	✅ DONE	R1: Gemini 9/10 + GPT 8.3/10 / R2: Gemini 9.8/10 APPROVE FINAL + GPT 9.1/10 APPROVE WITH MINOR
3	Apply 7 fix inline R2	✅ DONE	(1) dot_config nullable+UTC ISO (2) H14 grace_never_set (3) fn_log_issue bỏ severity (4) precheck dedupe system_issues (5) infer fail CẤM POST partial (6) H13 chỉ báo động (7) BLOCK 4 +4.0 snapshot +4.3 old_file_path +4.10 atomic +4.13 cleanup
4	Backup v5.0 + SUPERSEDED draft	✅ DONE	`dieu35-dot-governance-law-v5-0-backup.md` rev 1, draft rev 11 đánh dấu SUPERSEDED
5	HP cập nhật v4.5.1 → v4.5.2	✅ DONE	`constitution.md` rev 17 — mục lục Đ35 + changelog v4.5.2
6	Memory #24 ghi nhận ban hành	✅ DONE	5 post-merge TODO

Thứ tự triển khai THỰC TẾ (post-merge — phiên sau làm ngay, theo thứ tự, không nhảy bước):

#	Việc	Ưu tiên	Phụ thuộc	File/DOT liên quan
T1	Tạo `retrofit-audit-tracker.md` theo dõi Đ36/37/38/39/41	CRITICAL	—	`knowledge/current-state/retrofit-audit-tracker.md` (mới)
T2	Vá `dot-dot-register`: payload 11 fields + infer logic + CẤM POST partial	CRITICAL	—	VPS `/opt/incomex/dot/bin/dot-dot-register`
T3	BẬT Directus flow `[AUTO-ID] DOT Tools` ACTIVE	CRITICAL	—	Directus UI Flows
T4	Tạo DOT mới `dot-metadata-repair` (Tier B, cron 1h) paired `dot-dot-health`	HIGH	T2	—
T5	Amend OR soạn luật v1.0 → v1.1: checklist Gap-1 (prompt đối chiếu §4+§9, ghi TÊN không chỉ số)	HIGH	—	`knowledge/dev/ssot/operating-rules-law-drafting.md`
T6	Thêm AP-22 vào `anti-patterns.md`: "Đếm số không đo tên"	HIGH	—	`knowledge/dev/ssot/anti-patterns.md`
T7	Update Skill Handoff v7: bắt buộc ghi TÊN khi ghi N artifact + lint DOT	MEDIUM	T6	`knowledge/dev/ssot/skill-handoff-quality.md`
T8	CHẠY BLOCK 4 CHECKLIST §9.2 — 13 bước từ 4.0 snapshot → 4.13 cleanup (ước 1-2 ngày, bao gồm 24h observation)	CRITICAL	T2+T3+T4 DONE	Đ35 v5.1 §9.2
T9	Sau BLOCK 4 PASS: `UPDATE dot_config SET value=to_char(NOW() AT TIME ZONE 'UTC',...) WHERE key='law_v5_1_enacted_at'`	CRITICAL	T8 PASS	—
T10	Kick 6 DOT birth-related còn `last_executed=NULL` (DOT_BIRTH_BACKFILL, METADATA_AUDIT, METADATA_FILL, KG_COMPLETENESS, SCHEMA_BIRTH_REGISTRY_ENSURE, BIRTH_TRIGGER_SETUP)	CRITICAL	T8 (trong BLOCK 4)	VPS `/opt/incomex/dot/bin/*`
T11	Audit chéo Đ36/37/38/39/41 theo §11.4 — tìm luật cần amend retrofit	HIGH	T1	Tracker T1
T12	Fix TD-KB-OWNER-DRIFT: `ALTER TABLE {kb_documents,_history,audit_log} OWNER TO workflow_admin`	MEDIUM	—	3 bảng PG trên VPS
T13	Sau 7 ngày BLOCK 4 PASS ổn định: DROP `dot_tools_pre_v5_1` + `system_issues_pre_v5_1` snapshot tables	MEDIUM	T8 PASS + 7 ngày	—
T14	Tiêu chí cứng `warn → block` (4 điều kiện AND §10) đạt → `UPDATE dot_config SET value='block' WHERE key='birth_gate_mode'`	HIGH	T8 + 3 ngày H10-14 PASS	—

Timeline ước tính:

T1-T7: song song, 1 phiên (2-4h) — công việc văn bản + vá script
T8 BLOCK 4: 1-2 ngày (bao gồm 24h observation)
T9-T10: kèm trong T8
T11: 1 phiên audit + amend từng luật (có thể kéo dài nhiều ngày)
T12: 1 lệnh
T13-T14: chờ (tự động kích hoạt khi đủ điều kiện)

§13.6 — GAP-5 CHỐT: KHÔNG cần Điều 42 MỚI

Phạm vi 2 cơ chế Phase 1+2 = chỉ kb_documents. Script/config/code VPS dựa vào git backup 2×/ngày + .bak tay (phương án A chốt Huyên 2026-04-14). Không đẻ luật mới cho layer này.