QUY ĐỊNH KHO TẠM LEGO

Mã tài liệu: KHO-TAM-LEGO-ROOT-001 Đường dẫn: knowledge/dev/laws-new/kho-tam/quy-dinh-kho-tam.md Phiên bản: DRAFT v2 — CHỜ OWNER REVIEW Ngày viết lại: 2026-06-24 (rà soát + viết lại theo SSOT /laws-new/) Bản trước: v1 (GPT) đã archive tại knowledge/dev/laws-new/kho-tam/archive/quy-dinh-kho-tam-draft-v1-before-ssot-review.md Báo cáo rà soát: knowledge/dev/laws-new/reports/kho-tam-root-doc-ssot-rewrite/

0. Trạng thái tài liệu, thứ tự SSOT, phạm vi

0.1 Trạng thái

DRAFT v2 — CHỜ OWNER REVIEW. Chưa BAN HÀNH. Tài liệu này KHÔNG cho phép: production mutation, DDL, deploy, triển khai DOT, ghi registry/catalog chính thức, approval/quorum, hay tạo DB/schema/sandbox. Nó chỉ là căn cước gốc dạng văn bản cho cơ chế kho tạm, để owner duyệt trước khi bất kỳ DOT nào được dựng.

0.2 Định vị tài liệu (chống hiểu nhầm)

Tài liệu này là quy định cơ chế cô lập vật lý/vận hành cho lane kho tạm LEGO, nối vào mô hình SSOT đã có: ma trận Tầng × Loài × Kho × Miền, hệ stamp (TEMP_ID/BIRTH/…), và substrate staging đang chạy thật. Đây KHÔNG phải một hệ staging thứ hai. "Kho tạm" không phải một phát minh mới — nó là một giá trị của trục Kho (kho tạm · kho chính · canonical) trong ma trận đã được định nghĩa.

0.3 Thứ tự ưu tiên SSOT (precedence)

Nếu tài liệu này mâu thuẫn với các nguồn dưới đây, nguồn cao hơn thắng:

1. Luật đã BAN HÀNH trong knowledge/dev/laws/ (vd Điều 41 v1.1, Điều 0-B composition-level-law).
2. Ba file SSOT đang hiệu lực của track laws-new:
   - matrix-refactor-implementation-plan.md
   - matrix-refactor-quick-rules.md
   - matrix-stamp-governance-addendum.md
   (theo README laws-new: "the three files above win" mọi xung đột trong folder.)
3. Quy định vận hành staging lane: WF-draft/08-lego-staging-speed-principle, WF-draft/06-staging-lane-simplified-approval-policy.
4. Tài liệu này (kho-tam root doc).

Chỗ nào SSOT chưa rõ hoặc mâu thuẫn nội bộ → tài liệu này ghi HOLD — cần owner quyết định (xem §16), KHÔNG tự đặt chuẩn mới song song.

0.4 Phạm vi

Trong phạm vi: định nghĩa kho tạm; vị trí trong ma trận; mức độ giống kho chính; cơ chế cô lập vật lý; factory chung; base vs run; substrate tái dùng; bộ DOT đề xuất; cách gọi; quy trình tạo/sync/xóa; evidence dry-run; nguyên tắc promote (chỉ nguyên tắc).

Ngoài phạm vi (tài liệu riêng sau, owner-gated): quy trình promote chi tiết từ kho tạm vào kho chính; thiết kế DDL của bất kỳ DOT nào; materialize cell_id.

1. Định nghĩa kho tạm theo SSOT

Kho tạm (LEGO staging) là trạng thái "kho tạm" của trục Kho trong ma trận, nơi một miếng LEGO (object/process/DOT/candidate) được lắp thử → kiểm nhanh → sai thì xóa → đúng thì promote, cô lập khỏi kho chính, và output luôn chỉ là thông tin/candidate, không bao giờ là thay đổi đã áp.

Căn cứ SSOT (verbatim):

matrix-refactor-quick-rules.md rule 8: "Mặc định mọi triển khai mới đi vào kho tạm: mở ô tạm → lắp thử → kiểm nhanh → sai thì xóa → đúng thì promote."
matrix-refactor-quick-rules.md rule 9: "Không ghi thẳng kho chính/canonical. Kho chính chỉ nhận qua promote."
matrix-refactor-implementation-plan.md §12.5 / M-6: "Output kho tạm là thông tin/candidate — không bao giờ là thay đổi đã áp." ("Sandbox output is information… never an applied change.")
WF-draft/08-lego-staging-speed-principle.md: mục đích kho tạm = build quickly; try in practice; see real failures; fix quickly; delete quickly if wrong; only promote later if the piece proves useful.

Đặc điểm danh tính: object trong kho tạm mang TEMP_ID_STAMP (workspace_id/candidate_id), chưa khai sinh canonical. Khai sinh canonical (BIRTH_STAMP + birth_id/entity_code) chỉ xảy ra một lần khi promote pass (quick-rules rule 12; stamp-addendum §3, §7).

Nói ngắn:

Kho tạm = ô "kho tạm" của trục Kho: nơi thử nhanh một miếng LEGO,
cô lập, có TEMP_ID_STAMP, output là candidate, xóa nhanh được, promote là việc khác.

2. Kho tạm nằm ở đâu trong ma trận Tầng × Loài × Kho × Miền

SSOT (laws-new README + implementation-plan §3) định nghĩa ma trận định vị 4 chiều. Mỗi ô (cell) chứa: Công thức + DOT + Governance state + IO Contract.

Chiều	Ý nghĩa (verbatim SSOT)	Liên quan kho tạm
Tầng	6 tầng lắp ráp: nguyên tử → phân tử → hợp chất → vật liệu → thành phẩm → công trình	Miếng LEGO thuộc một tầng (composition_level).
Loài	Nhóm đối tượng cùng bản chất, cùng cách quản lý (Đ29; species tree)	Miếng LEGO thuộc một loài (species).
Kho	Nơi lưu theo tầng/loài/trạng thái: kho tạm · kho chính · canonical	Kho tạm là một GIÁ TRỊ của trục này.
Miền	Miền chuyên môn/nghiệp vụ (jurisdiction, Đ37)	Miếng LEGO thuộc một miền.

Hệ quả định vị: một lần "tạo kho tạm" thực chất là mở một ô tạm tại toạ độ (tầng, loài, kho=tạm, miền). Đây là cách định danh đúng — KHÔNG phải --scope C1/C2 như bản v1. C1 là tên một miếng LEGO/payload cụ thể, không phải một chiều của ma trận.

Toạ độ ô = cell_id (tầng, loài, kho, miền) (implementation-plan §3.4, IO-contract schema §11: cell_id: {layer, species, collection, domain}).

⚠️ HOLD quan trọng: cell_id CHƯA được materialize (chưa có cột/metadata trong runtime). Có xung đột mở "6-vs-7 tầng" (CONS-003) và dieu36-collection-protocol-amendment-draft đang chặn việc materialize cell_id/Species-Matrix khi CONS-003 còn mở. Live PG xác nhận: không có cột cell_id trong schema. ⇒ Tài liệu này dùng toạ độ 4 chiều như mô hình định vị khái niệm, KHÔNG được coi cell_id là đã có. Xem §16.

Thuật ngữ "Tầng" vs "Lớp": Luật Điều 0-B gọi 6 cấp cấu tạo là "Lớp" (Lớp nguyên tử…), và dành chữ "Tầng" cho kiến trúc 5 tầng hạ tầng. Track laws-new (matrix) tái dùng chữ "Tầng" cho trục lắp ráp 6 cấp và đã ghi rõ cảnh báo trùng tên. Trong tài liệu này, "Tầng" = trục 6 cấp composition_level. Đây là điểm dễ nhầm → ghi HOLD ở §16 để owner chốt từ ngữ.

2.1 Enum tầng (composition_level) — ĐÚNG theo SSOT + live

Bản v1 dùng atom/molecule/cell/organ/building/system — SAI. cell/organ/system không tồn tại trong SSOT; thiếu compound/material/product.

Enum canonical đúng (Điều 0-B composition-level-law.md):

atom (Lớp 1) → molecule (Lớp 2) → compound (Lớp 3) → material (Lớp 4) → product (Lớp 5) → building (Lớp 6)
+ meta  (giá trị riêng cho thực thể "Loài"/species, đứng NGOÀI 6 lớp)

Live PG xác nhận (distinct composition_level): meta_catalog có đủ {atom, molecule, compound, material, product, building, meta}; birth_registry có {atom, molecule, compound, meta} (1.2M+ atom); entity_species có {atom, molecule, compound, meta}. Không có cell/organ/system ở bất kỳ đâu.

⇒ Mọi tham số --layer trong tài liệu này dùng đúng 6 giá trị canonical (không dùng meta cho miếng LEGO thường — meta chỉ cho thực thể Loài).

3. Kho tạm giống kho chính đến mức nào

Nguyên tắc: giống ở những điểm quyết định khả năng chạy đúng, không giống về toàn bộ dữ liệu. Cụ thể 4 tiêu chuẩn tối thiểu:

3.1 IO Contract — TRUNG TÂM, không phải phụ

IO Contract là một trong 4 thành phần bắt buộc của mỗi ô (README: "Trong mỗi ô: Công thức · DOT · Governance state · IO Contract"), và IO_STAMP là precondition promote (stamp-addendum §7). Vì vậy:

Miếng LEGO phải chạy trong kho tạm bằng đúng IO Contract dự kiến dùng ở kho chính.
Nếu buộc rút gọn/mock một phần, report dry-run phải ghi: contract nào giữ nguyên, contract nào mock, và vì sao mock không làm sai kết quả kiểm thử.
Kho tạm pass mà IO Contract sai lệch ⇒ kết quả vô nghĩa ⇒ đây là một trong các rủi ro phải chặn (xem §13).

3.2 Schema / contract shape

Kho tạm cần phần schema/bảng/view tương đương phần mà miếng LEGO chạm tới (projection). Không bắt copy toàn bộ schema.

Thử cái gì thì schema/contract của cái đó phải đủ giống.
Không thử cái gì thì không cần copy.

3.3 Behavior / fail-closed

Kho tạm phải fail-closed theo cùng logic tối thiểu: input sai bị reject; bad-case không được tính PASS nếu sai kỳ vọng; evidence không được báo PASS nếu valid/bad/cleanup chưa đủ. (Đồng bộ với VALIDATION_STAMP = bộ FIX7 rút gọn, bad-input ≥8 lớp, any_fail_open=false — stamp-addendum §4.)

3.4 Dữ liệu / fixture tối thiểu

Seed nhỏ, fixture rõ, copy-on-write nếu cần.
CẤM TUYỆT ĐỐI đưa PII thật / secret thật / authority row thật vào seed (WF-draft/06 §5: cấm hardcode secret, cấm hardcode fake approval row). Seed phải là dữ liệu tổng hợp/giả lập.
Determinism: seed/clock/random của dry-run nên tất định (fixed seed, fixed/injected timestamp) để kết quả tái lập và so sánh được. Tránh phụ thuộc thời gian thực/ngẫu nhiên trong oracle kiểm thử.

4. Cơ chế cô lập vật lý — chọn theo Điều 41, không tự chế

Điều 41 v1.1 (BAN HÀNH) §2A đã định nghĩa 4 vùng vận hành và lớp truy cập DB S0–S5. Kho tạm PHẢI map vào các lớp này, KHÔNG phát minh mô hình cô lập riêng.

Bốn vùng (Đ41 §2A.1): Active runtime (FORBIDDEN) · Trusted source/staging (không ghi trực tiếp) · Agent sandbox (được code/test/break/fix) · Runtime state/config (FORBIDDEN). Kho tạm sống trong vùng Agent sandbox.

Menu cô lập (chọn mức nhẹ nhất đủ dùng):

Mức	Cơ chế	Lớp Đ41	Dùng khi	Rollback/cleanup
R0 — Record-level candidate	Một dòng candidate trong bảng staging có sẵn (`iu_core.iu_staging_record` + payload; hoặc `governance_candidate_*`)	S1/S2	Thử nội dung/metadata/candidate không cần DDL	Đổi `lifecycle_status`→rejected/cleaned; xóa theo `staging_record_id`
R1 — Transaction rollback	Chạy trong 1 transaction rồi ROLLBACK	S4 (proof)	Proof read-mostly / chứng minh không vỡ trên bản thật, không giữ thay đổi	ROLLBACK tự động; post-count verify
R2 — Schema sandbox	Schema riêng `sandbox_<id>` (mẫu đang chạy: `sandbox_tac` soi gương `cutter_governance`)	S2	Thử cấu trúc/object/DDL ở mức schema	`DROP SCHEMA sandbox_<id> CASCADE` (1 lệnh)
R3 — Database sandbox	Database riêng `sandbox_<id>` cùng engine/version gần production	S2	Thử toàn hệ / migration nặng, cách ly tối đa	`DROP DATABASE sandbox_<id>` (1 lệnh)

Quy tắc chọn: dùng mức nhẹ nhất đủ để kiểm đúng. Đa số dry-run miếng LEGO nhỏ chỉ cần R0 hoặc R2. R3 chỉ cho thứ thật sự cần cách ly DB.

Cleanup bắt buộc theo cấu trúc (Đ41 §2A.6) — KHÔNG chỉ tin manifest (xem §12).

5. Một factory chung hay mỗi lớp một kho?

Quyết định: MỘT factory chung, tham số hoá theo toạ độ ô; KHÔNG mỗi tầng/loài tự chế staging riêng.

Lý do: giữ một chuẩn tạo/xóa/sync thống nhất; tránh "mỗi lớp một quái vật staging"; cải thiện an toàn/tốc độ chỉ sửa một chỗ. Đồng bộ WF-draft/06 §6 (bộ procedure staging "PG-native and thin… should not become a workflow engine") và WF-draft/08 ("Do not build a monster").

Quan trọng — phân biệt cái gì được generic:

Lớp sandbox (create/drop/status) ĐƯỢC generic — đây chính là factory chung, và đã có mầm thật: dot-staging-sandbox-create/-drop (staged ở C1).
Lớp authorization/handler KHÔNG được generic — dot-manage addendum §8–9: "Do not build a generic authorization system… handler must be C1-only." Tức factory tạo sandbox thì chung, nhưng logic nghiệp vụ/handler của từng miếng LEGO (payload) phải riêng, không gộp thành framework cấp phép vạn năng.

Mapping chuẩn:

factory chung (sandbox create/drop/status)  →  generic, dùng cho mọi (tầng, loài, miền)
payload nghiệp vụ của từng miếng LEGO        →  riêng (vd dot-c1-*), factory chỉ CHẠY payload trong sandbox

6. Base template vs run sandbox

6.1 Có dùng mô hình base + run không?

Có thể, nhưng không bắt buộc cho mọi mức. Mô hình base chỉ có giá trị cho R2/R3 (schema/DB sandbox) để khỏi rebuild từ đầu mỗi lần. Với R0 (record-level) thì không cần base.

6.2 Base có phải SoT không? — KHÔNG

Base template KHÔNG BAO GIỜ là nguồn sự thật (SoT). Base chỉ là projection phái sinh từ kho chính, có provenance hash. Kho chính vẫn là SoT duy nhất; kho chính chỉ nhận thay đổi qua promote (quick-rules rule 9). Một base mà "trôi" và bị coi là thật sẽ tạo second SoT ẩn — đây là rủi ro phải chặn.

6.3 stale-after / base_hash gate (BẮT BUỘC nếu dùng base)

Để base không trở thành second SoT, mỗi base phải mang:

source_ref + source_hash (hash của phần kho chính mà base soi gương);
built_at + stale_after (TTL của base);
Mỗi run sandbox ghi lại base_ref@<hash> đã clone từ đó.

Gate: khi source_hash hiện tại của kho chính ≠ source_hash của base, hoặc quá stale_after ⇒ base bị đánh dấu STALE; phải sync lại trước khi tạo run mới. (Đồng bộ nguyên tắc stale-after trong quick-rules/stamp-addendum và cột "stale-after" của governance_candidate_state.)

7. Substrate staging hiện có — DÙNG LẠI, không dựng mới

Đây là phần bản v1 bỏ sót hoàn toàn. Khảo sát live (read-only, 2026-06-24, DB directus) cho thấy substrate kho tạm đã tồn tại và đang chạy:

Substrate	Trạng thái live	Vai trò khả dụng cho kho tạm
`iu_core.iu_staging_record` (15 dòng) + `iu_core.iu_staging_payload` (32 dòng)	Đang dùng thật (cut-pipeline + "D36 Macro A proof bounded test")	Kho tạm cấp record (R0): có sẵn `lifecycle_status`, `owner_actor`, `purpose`, `expires_at` (TTL), `consumed_at`/`consumed_by_run_id` (promote), `cleaned_at` (cleanup), `approval_doc_id`/`approved_by` (light approval), `content_hash`/`idempotency_key`, `referenced_iu_ids`. + view observability.
`sandbox_tac` (schema, ~9 bảng + index lifecycle) soi gương `cutter_governance` (canonical)	Đang dùng thật	Mẫu kho tạm cấp schema (R2) đã chứng minh: canonical ↔ sandbox song song; `change_set`/`unit_version`/lifecycle; kho chính `cut_change_set` có `idempotency_key`+`rollback_key` = cơ chế promote/rollback.
`governance_candidate_object` + `governance_candidate_state`	Tồn tại nhưng 0 dòng (design-only, chưa dùng)	Lớp candidacy (group-grain, stale-after, fail-closed). SSOT đánh dấu BUILD NO-GO. ⇒ HOLD: chưa đưa vào vận hành.
Điều 41 §2A zones + S0–S5	Luật BAN HÀNH	Khung cô lập vật lý (đã dùng ở §4).

Quyết định: Kho tạm PHẢI nối vào substrate này, không dựng lego_sandbox_base / lego_sandbox_run_* song song như v1.

⚠️ HOLD (§16): Chọn substrate chính cho kho tạm LEGO (record-level dùng lại iu_staging_record? hay schema-level theo mẫu sandbox_tac? hay kích hoạt governance_candidate_state?) là quyết định của owner. Mỗi cái có ngữ nghĩa riêng: iu_staging_record đang gắn domain Information-Unit/cut-pipeline; sandbox_tac gắn domain cutter. Có thể cần một bảng staging generic mới đặt trong iu_core theo đúng khuôn iu_staging_record — nhưng việc đó là DDL governed, owner-gated, KHÔNG làm trong tài liệu này.

8. DOT tạo kho tạm — reuse-first, đặt tên theo incumbent

Khảo sát reuse-first (live): dot_tools có 0 DOT khớp sandbox/staging/lego/promote. Tức chưa có DOT chính thức nào cho kho tạm. Nhưng đã có DOT staged (chưa official) ở /opt/incomex/staging/c1/bin/: dot-staging-sandbox-create, dot-staging-sandbox-drop (tạo/xoá DB tạm c1_staging_<ts> + registry sbx_meta trong sandbox).

⇒ Namespace incumbent là dot-staging-sandbox-*, KHÔNG phải dot-lego-sandbox-* do v1 tự đặt. Đẻ thêm namespace mới = vi phạm reuse-first.

⚠️ HOLD (§16): Chốt namespace cuối cùng (dot-staging-sandbox-* đang có vs tên khác) là owner-decision. Tài liệu này đề xuất tái dùng/tiến hoá dot-staging-sandbox-*.

Bộ DOT tối thiểu đề xuất (thin, đúng "No lane before checker"):

dot-staging-sandbox-create   (ĐÃ staged) — mở ô tạm, trả manifest machine-readable
dot-staging-sandbox-drop     (ĐÃ staged) — xoá theo cấu trúc, fail-safe
dot-staging-sandbox-status   (đề xuất)   — liệt kê sandbox/base, TTL, owner, lifecycle, evidence path
dot-staging-sandbox-checker  (đề xuất, BẮT BUỘC trước mọi lane promote) — checker fail-closed block-mode

Hoãn lại (KHÔNG dựng vội):

dot-staging-sandbox-sync          — chỉ cần khi đã dùng base R2/R3 thật (xem §11); chưa cần cho R0.
dot-staging-sandbox-promote-plan  — thuộc promotion lane, tài liệu riêng (§14). KHÔNG dựng cùng đợt này.

"No lane before checker" (quick-rules rule 32, verbatim): "chưa có checker fail-closed chạy block-mode thì lane chưa mở. A paper lane is no lane." ⇒ Không được mở lane promote nào trước khi có checker fail-closed chạy block-mode. Bản v1 đề xuất promote-plan mà không có checker — vi phạm rule 32. Đã sửa: checker là điều kiện tiên quyết, promote-plan hoãn.

Mỗi DOT mới phải có "8-facet lifecycle" (dot-manage addendum §10) khi thực sự dựng: why-not-reuse, birth, admission, registration, registry readback, ledger readback, rollback/retire, orphan-check. (Đây là việc của giai đoạn triển khai sau khi owner duyệt, KHÔNG làm bây giờ.)

9. Cách gọi tạo kho tạm — theo toạ độ ô, enum đúng

Chuẩn gọi đề xuất (tham số phản ánh 4 chiều ma trận, không dùng --scope mơ hồ):

dot-staging-sandbox-create \
  --layer compound \                 # composition_level: atom|molecule|compound|material|product|building
  --species workflow \               # loài (species_code theo entity_species/Đ29)
  --kho tam \                        # trục Kho = tạm (mặc định cho lane này)
  --domain <jurisdiction> \          # miền (Đ37); để trống nếu hạ tầng chung
  --piece c1 \                       # tên miếng LEGO/payload cụ thể (KHÔNG phải một chiều ma trận)
  --isolation R0|R2|R3 \             # mức cô lập theo §4
  --purpose "C1 canonical_operation fast LEGO dry-run" \
  --ttl 24h \
  --owner nmhuyen@gmail.com

Output bắt buộc machine-readable (JSON/env-file), tối thiểu:

{
  "sandbox_id": "sbx_<layer>_<species>_<piece>_<yyyymmddHHMMSS>_<shortid>",
  "cell_coords": {"layer": "compound", "species": "workflow", "kho": "tam", "domain": null},
  "isolation": "R2",
  "base_ref": "<base@hash | null nếu R0>",
  "ttl": "24h",
  "owner": "nmhuyen@gmail.com",
  "temp_id_stamp": "<workspace_id/candidate_id>",
  "cleanup_command": "dot-staging-sandbox-drop --sandbox-id <sandbox_id>",
  "created": true
}

Lưu ý: cell_coords chỉ là nhãn định vị, KHÔNG ghi vào cột cell_id runtime (chưa materialize — §2 HOLD).

10. Quy trình tạo một kho tạm mới

B1 — Pre-check
   • Xác định toạ độ ô (layer/species/kho=tạm/domain) + mức isolation tối thiểu đủ dùng.
   • Nếu dùng base (R2/R3): kiểm base STALE? (base_hash vs kho chính, stale_after) → sync nếu cần.
   • Reuse-first: có sandbox/candidate cũ tái dùng được không?

B2 — Create
   • Gọi dot-staging-sandbox-create → nhận sandbox_id + manifest + TEMP_ID_STAMP.
   • Object trong sandbox mang TEMP_ID_STAMP, KHÔNG khai sinh canonical.

B3 — Run payload LEGO trong sandbox
   • Payload (vd dot-c1-*) nhận --sandbox-id từ factory; payload KHÔNG tự tạo kho.
   • DOT 100% ở cấp operation: dùng primitive, KHÔNG raw SQL tay vào bảng official.

B4 — Validate IO + fail-closed
   • Chạy valid cases (phải PASS) và bad cases (phải fail-closed, đúng reject_code/SQLSTATE kỳ vọng).
   • Kiểm IO Contract đúng (IO_STAMP). Bad-case PASS sai = chặn.

B5 — Evidence staging-local (§13)
   • Ghi raw evidence đủ đọc lại (sandbox_id, base_ref, commands, valid/bad, official-unchanged snapshot, cleanup cmd, verdict).
   • KHÔNG ghi promotion-grade stamp chain ở bước này.

B6 — Cleanup / drop (hoặc giữ theo TTL có lý do)
   • Mặc định sau dry-run: dot-staging-sandbox-drop --sandbox-id <id>.
   • Giữ lại để debug thì report phải ghi: lý do, TTL, owner, cleanup cmd, rủi ro.

11. Quy trình sync khi kho chính đổi

Chỉ áp dụng khi đã dùng base R2/R3. Cơ chế:

1. Read-only snapshot phần kho chính mà base soi gương.
2. Tính source_hash hiện tại; so với base.source_hash.
3. Nếu khác (schema/contract đổi) HOẶC quá base.stale_after → base = STALE.
4. dot-staging-sandbox-sync: cập nhật base projection + ghi manifest:
   source_ref, source_hash mới, schema projection, timestamp, DOT run id, evidence ref.
5. Run sandbox MỚI clone từ base mới.

Khi nào BUỘC sync: trước khi tạo run mới mà base đang STALE; hoặc khi kho chính đổi schema/contract của phần đang thử. Sandbox đang chạy dở KHÔNG bắt buộc rebuild — được tiếp tục theo base version cũ, nhưng report phải ghi base version (để biết kết quả thử thuộc bản nền nào).

12. Quy trình xóa — fail-safe theo state + bằng cấu trúc

12.1 Lifecycle state — chỉ xóa trạng thái an toàn

SSOT (quick-rules S14 + stamp-addendum §7c, verbatim): "Cleanup CHỈ được xóa candidate ở trạng thái draft / expired / quarantined. Cleanup KHÔNG được xóa candidate đang checking / promote_ok-chưa-consumed / approved / đang promote. Cleanup fail-safe: nghi ngờ thì KHÔNG xóa."

Allowlist xóa (cứng): draft, expired, quarantined (và tương đương live iu_staging_record: rejected, consumed đã đóng, pending quá expires_at). Denylist (cấm xóa): checking, promote_ok-chưa-consumed, approved, đang promote. Mặc định: nghi ngờ / không xác định state → KHÔNG xóa.

⚠️ HOLD (§16) — xung đột từ ngữ lifecycle: từ vựng state của SSOT-addendum (draft/expired/quarantined/checking/promote_ok/approved) KHÁC từ vựng live của iu_core.iu_staging_record (pending/pending_review/approved/rejected/consumed). Cần owner chốt một bảng ánh xạ/đồng nhất, KHÔNG tự đẻ từ vựng thứ ba.

12.2 Xóa bằng CẤU TRÚC, không chỉ tin manifest

Theo Điều 41 §2A.6 — cleanup phải an toàn bằng cấu trúc, không tin chữ:

• R2 (schema): DROP SCHEMA sandbox_<id> CASCADE  — chỉ với schema có tiền tố sandbox_ hợp lệ.
• R3 (database): DROP DATABASE sandbox_<id>       — chỉ với DB có tiền tố sandbox_ hợp lệ.
• R0 (record): DELETE ... WHERE sandbox_run_id/staging_record_id = '<id>'
   CHỈ KHI mọi dòng được tag đầy đủ, có precheck count, KHÔNG trộn dòng production.

Tuyệt đối KHÔNG xóa: kho chính; canonical; base template (trừ khi có DOT riêng + owner xác nhận); sandbox không có manifest/provenance rõ; sandbox của run khác chưa xác định đúng owner/run_id. Sandbox bị cấm symlink-write vào active runtime/trusted source/runtime state.

Ghi evidence: drop_attempt / drop_success / drop_failed (cleanup-fail phải fail-closed, không báo success giả).

13. Evidence tối thiểu cho dry-run

Bắt buộc (đủ đọc lại):

sandbox_id · cell_coords · isolation · base_ref(+version) · owner/operator · created_at · ttl
commands đã chạy · valid result · bad result(reject_code/SQLSTATE) · IO check
official runtime "before==after" snapshot (nếu chạm gần) · cleanup/drop result · KB evidence path · final verdict

KHÔNG bắt buộc ở giai đoạn dry-run (thuộc promotion lane): full promotion-grade digest, full stamp chain, approval/quorum, official catalog registration.

Quy tắc 6-rủi-ro (WF-draft/08, verbatim tinh thần): với dry-run, chỉ chặn khi issue gây một trong: (1) official runtime mutation; (2) false valid-case PASS; (3) false bad-input PASS; (4) cleanup/drop fail bị giấu thành success; (5) sandbox orphan không xoá được; (6) raw evidence không đọc được. Nếu chỉ là thiếu binding stamp/digest promotion-grade ⇒ ghi PROMOTION_LANE_TODO, KHÔNG chặn dry-run.

Nơi ghi evidence (không làm bẩn KB chính): evidence dry-run sống ở staging-local — metadata của staging record (iu_staging_record.metadata), hoặc report KB trong nhánh reports/ của lane, KHÔNG ghi vào canonical birth/registry hay luật đã ban hành. Stamp nhẹ cho dry-run: TEMP_ID_STAMP (bắt buộc), IO_STAMP + VALIDATION_STAMP (nên có vì là precondition promote sau này); CELL/ROLLBACK/BIRTH/PROMOTE thuộc promote.

14. Tiêu chuẩn promote — chỉ nguyên tắc

Tài liệu này không định nghĩa quy trình promote chi tiết (tài liệu riêng, owner-gated: kho-tam/quy-trinh-promote-tu-kho-tam-vao-kho-chinh.md). Nguyên tắc tối thiểu:

Một kết quả kho tạm chỉ là ứng viên promote nếu: chạy PASS trong run sandbox; có raw evidence đọc lại được; IO Contract đúng; không đụng kho chính khi thử; có diff/plan sandbox→kho chính.

Cổng cứng (SSOT):

"No lane before checker": chỉ mở lane promote khi đã có checker fail-closed chạy block-mode (quick-rules rule 32).
Atomic Promote Contract (stamp-addendum §7b): "PROMOTE_OK là verdict, KHÔNG phải mutation." Tạo birth + đóng BIRTH/PROMOTE + consume staging = một transaction riêng sau checker, all-or-nothing.
Promote là Mức 2 trong 3 mức governance (Mức 1 kho tạm → Mức 2 promotion fail-closed → Mức 3 canonical/kernel Đ32 đầy đủ).

Trước khi có tài liệu promote + checker, mọi kết quả kho tạm chỉ là kết quả thử, không phải kết quả chính thức.

15. C1 hiện tại nên giữ / sửa / bỏ gì

Hiện trạng (khảo sát): C1 ở /opt/incomex/staging/c1/ (KHÔNG phải official dot/bin), gồm dot-staging-sandbox-create/-drop (generic) + dot-c1-staging-vocab-build/-verify/-bad-input-harness/-evidence-readback (C1-specific) + registry/ledger JSONL staging + plan. Chưa từng tạo sandbox DB nào (staging_DBs=0), đang kẹt ở Codex R4 (CODEX_REJECT_C1_STAGING_R4_DOT_STAMPING_INCOMPLETE).

Đánh giá kiến trúc:

Phần C1	Bản chất	Khuyến nghị
`dot-staging-sandbox-create` / `-drop`	Factory sandbox generic (đặt tên `dot-staging-*`, tạo DB tạm bất kỳ)	GIỮ + nâng thành factory chung §8. Đây là mầm factory đúng.
`dot-c1-staging-vocab-build/-verify/-bad-input-harness`	Payload C1 (nghiệp vụ riêng)	GIỮ làm payload chạy trong sandbox; KHÔNG generic hoá thành framework.
`dot-c1-staging-evidence-readback` (P6 thành "forgery-proof oracle", digest/stamp chain, 4 vòng Codex)	Overbuilt — đúng "production evidence drift" mà WF-draft/08 cảnh báo	CẮT BỚT về mức 6-rủi-ro (§13). Phần stamp/digest completeness ghi `PROMOTION_LANE_TODO`, không chặn dry-run.
Vòng review R1→R4 + self-gate + digest binding hoàn chỉnh trên sandbox chưa từng dựng	Quy trình promotion-grade áp lên thứ chưa test thực tế	TẠM DỪNG leo thang; cho C1 chạy dry-run thật trong sandbox factory trước, rồi mới bàn promote.

Tóm tắt: C1 là minh hoạ sống của "staging monster" mà WF-draft/08 cảnh báo (bị kéo vào promotion-grade stamp/digest trước khi sandbox được thử thực tế). Cách chữa: tách factory chung (giữ) khỏi payload C1 (giữ) khỏi promotion-grade machinery (cắt/hoãn).

16. Các điểm HOLD cần owner quyết định

H1 — Từ ngữ "Tầng" vs "Lớp": laws-new dùng "Tầng" cho 6 cấp composition_level,
     Điều 0-B dùng "Lớp". Chốt từ ngữ thống nhất cho lane kho tạm.
H2 — cell_id CHƯA materialize (CONS-003 "6-vs-7 tầng", Đ36 amendment chặn).
     Kho tạm dùng toạ độ 4 chiều như nhãn khái niệm. Owner quyết khi nào materialize cell_id.
H3 — Substrate kho tạm chính: dùng lại iu_core.iu_staging_record (record-level)?
     theo mẫu sandbox_tac (schema-level)? kích hoạt governance_candidate_state (đang 0 dòng/BUILD NO-GO)?
     hay dựng bảng staging generic mới trong iu_core? (DDL governed, owner-gated.)
H4 — Xung đột từ vựng lifecycle: SSOT-addendum (draft/expired/quarantined/checking/promote_ok/approved)
     vs live iu_staging_record (pending/pending_review/approved/rejected/consumed). Cần bảng ánh xạ thống nhất.
H5 — Namespace DOT: tái dùng dot-staging-sandbox-* (incumbent đã staged) — xác nhận, hay đổi tên?
H6 — Bộ DOT MVP: tài liệu đề xuất create/drop/status/checker (thin), hoãn sync/promote-plan. Owner chốt phạm vi.
H7 — Quota/concurrency: chưa có SSOT về trần tài nguyên (số sandbox đồng thời, dung lượng, TTL tối đa).
     Đề xuất đặt trần mặc định nhẹ — cần owner cho con số.
H8 — Tài liệu promote riêng + checker fail-closed: khi nào khởi động (sau khi C1 dry-run thật xong?).

17. Bước tiếp theo sau khi owner duyệt

1. Owner review DRAFT v2 + chốt H1–H8 (§16).
2. Chốt substrate (H3) + namespace (H5) + bộ DOT MVP (H6).
3. Thiết kế DDL/skeleton cho factory chung (governed, có 8-facet lifecycle) — KHÔNG trong tài liệu này.
4. Viết checker fail-closed block-mode TRƯỚC mọi lane promote (rule 32).
5. Cho C1 chạy dry-run thật trong sandbox factory (R0/R2) — cắt bớt promotion-grade machinery (§15).
6. Sau khi có dry-run thật + checker: viết tài liệu promote riêng (§14), rồi mới bàn Mức 2.

Phụ lục A — Tóm tắt quyết định

• Kho tạm = giá trị "kho tạm" của trục Kho trong ma trận Tầng×Loài×Kho×Miền — KHÔNG phải hệ staging thứ hai.
• Enum tầng đúng: atom/molecule/compound/material/product/building (+meta cho Loài). (v1 sai: cell/organ/system.)
• Định danh theo toạ độ ô 4 chiều, KHÔNG --scope C1/C2. cell_id chưa materialize (HOLD).
• Cô lập theo Điều 41 S0–S5: R0 record / R1 txn-rollback / R2 schema / R3 DB — chọn mức nhẹ nhất đủ dùng.
• Một factory chung (sandbox generic) + payload riêng từng miếng (handler KHÔNG generic).
• Base KHÔNG là SoT; có base_hash + stale-after gate.
• Dùng lại substrate có thật (iu_staging_record/payload, sandbox_tac, Đ41 zones) — không dựng lego_sandbox_* mới.
• Reuse-first DOT: incumbent dot-staging-sandbox-* (đã staged), không đẻ dot-lego-sandbox-*.
• No lane before checker (rule 32): không mở lane promote trước khi có checker fail-closed block-mode.
• Xóa fail-safe theo state + bằng cấu trúc (DROP SCHEMA/DB theo tên; DELETE theo tag) — không chỉ tin manifest.
• Dry-run: evidence nhẹ staging-local, chặn theo 6-rủi-ro, không promotion-grade stamp chain.
• DOT 100% ở cấp operation; không raw SQL tay vào bảng official; không chạm runtime.
• Promote sang kho chính = lane riêng, tài liệu riêng, owner-gated.