03 — MÂU THUẪN PHÁT HIỆN

Phần A — Mâu thuẫn v1 (draft) ↔ SSOT (đã sửa trong v2)

#	Draft v1 nói	SSOT/live nói	Xử lý v2
A1	layer = atom/molecule/cell/organ/building/system	composition_level = atom/molecule/compound/material/product/building (+meta)	Sửa enum §2.1
A2	định danh --scope C1/C2	ô = (tầng,loài,kho,miền); C1 là tên LEGO	Toạ độ 4 chiều §2/§9
A3	im lặng về checker	rule 32 "no lane before checker"	Checker bắt buộc §8/§14
A4	xóa theo manifest	S14/§7c xóa theo state, fail-safe	§12 state + cấu trúc
A5	tự chế lego_sandbox_base/run_*	substrate thật iu_staging/sandbox_tac/Đ41	§7 nối substrate
A6	dot-lego-sandbox-* (mới)	incumbent dot-staging-sandbox-* đã staged	§8 reuse-first
A7	base có thể là nơi nền ổn định	kho chính là SoT duy nhất, nhận qua promote	§6.2 base ≠ SoT
A8	evidence "staging-local" mơ hồ	nơi ghi rõ ràng + 6-rủi-ro	§13
A9	không cấm PII/secret rõ	WF-06 §5 cấm tuyệt đối	§3.4
A10	không có cô lập theo lớp	Đ41 S0–S5	§4 menu R0–R3

Phần B — Mâu thuẫn NỘI BỘ SSOT (KHÔNG tự chọn — chuyển HOLD cho owner)

B1 — "Tầng" vs "Lớp" (từ ngữ):

• Điều 0-B (BAN HÀNH): 6 cấp cấu tạo gọi là "Lớp"; "Tầng nguyên tử" = SAI.
• laws-new matrix track: tái dùng "Tầng" cho trục lắp ráp 6 cấp, có ghi cảnh báo trùng tên. → Hai nguồn dùng từ khác nhau cho cùng khái niệm. Không đủ căn cứ tự chốt. → HOLD H1. (v2 tạm dùng "Tầng" theo matrix track + ghi rõ.)

B2 — cell_id: mô hình vs hiện thực:

• implementation-plan/README: ma trận 4 chiều, mỗi ô có cell_id.
• technical-slice-framework + Đ36 amendment: cell_id chưa thiết kế, 6-vs-7 tầng CONFLICT (CONS-003), materialize bị chặn.
• Live PG: không có cột cell_id. → SSOT vừa khẳng định mô hình vừa chặn hiện thực. → HOLD H2. (v2 dùng cell_id như nhãn khái niệm.)

B3 — Từ vựng lifecycle (design vs live):

• stamp-addendum/quick-rules S14: draft/expired/quarantined/checking/promote_ok/approved.
• Live iu_core.iu_staging_record: pending/pending_review/approved/rejected/consumed. → Hai bộ từ vựng state khác nhau cho cùng vòng đời candidate. → HOLD H4. (v2 ánh xạ tạm + cấm đẻ từ vựng thứ ba.)

B4 — Strict governance vs speed (định hướng):

• dot-manage addendum: DOT 100% mọi nơi, 8-facet lifecycle mỗi object, Codex stance bắt buộc → maximal.
• WF-08/WF-06: auto-approve, thin, lightweight, "do not build a monster" → minimal. → Hai định hướng kéo ngược nhau; chính là nguồn gốc "staging monster" của C1. v2 chọn đường WF-08/06 cho dry-run và giữ governance đầy đủ cho promote (3 mức của implementation-plan §10). Đây là cách hoà giải có căn cứ (phân tầng theo lane), nhưng ranh giới chính xác vẫn nên owner xác nhận → liên quan H6/H8.

B5 — governance_candidate_state: tồn tại vs BUILD NO-GO:

• Live: bảng tồn tại (DDL có) nhưng 0 dòng.
• SSOT addendum: đánh dấu "design-only, BUILD NO-GO". → Không mâu thuẫn cứng, nhưng cần làm rõ: bảng có shell nhưng chưa được phép đưa vào vận hành. → HOLD H3 (chọn substrate).

Kết luận

• Mâu thuẫn A1–A10: đã sửa theo SSOT trong v2.
• Mâu thuẫn nội bộ B1–B5: KHÔNG tự chốt; chuyển HOLD (07-hold-items-for-owner).