L4 Mở rộng Đ0-G — Birth Gate cho Text Unit + Component
MỞ RỘNG ĐIỀU 0-G — BIRTH GATE CHO TEXT UNIT + COMPONENT
L4 Điều 38
Trạng thái: DỰ THẢO — chờ Council review + User duyệt Loại: Mở rộng Đ0-G (Birth Registry Law v1.0) Tiền đề: L1 (Text Unit), L2 (Component/BOM), L3 (Metadata Governance) Đóng blocker: 02D0 blocker "Đ0-G chưa mở rộng scope cho text_unit + component" Che phủ hở: 02DX QĐ1 "Đ0-G chưa có species text_unit" + QĐ4 "birth gate component" GPT review: PASS, 12 chỉnh + 3 khuyến nghị đã áp dụng
§1. Mục đích
Mở rộng Đ0-G để birth gate bao phủ 2 species mới: text_unit và component. Đ0-G hiện hành đã chốt cơ chế phổ quát (birth_registry + inspectors + auto-certify), nhưng scope chưa bao gồm text unit và component. Phụ lục này bổ sung scope, không thay đổi cơ chế lõi của Đ0-G.
L4 không tự thay đổi Đ0-G schema. Nếu cần schema change cho birth_registry phải amend Đ0-G riêng.
L4 chỉ kiểm birth/completeness. Review/approval nội dung vẫn thuộc L5/Đ32.
Không làm: Không viết schema/trigger/function/DOT list cụ thể. Không thay đổi kiến trúc birth_registry. Không định nghĩa lại L1/L2/L3.
§2. Phạm vi
§2.1 Đ0-G hiện hành áp cho gì?
Đ0-G v1.0 áp cho mọi entity sinh ra trong PG thuộc governed collection. Cơ chế: INSERT → birth record → inspect (PEN/STAMP/GATE) → certified. Đã proven cho các entity hiện hành (registries, species, collections...).
§2.2 L4 mở rộng thêm gì?
Thêm 2 object family vào scope birth gate:
| Object family | Species mới | Đăng ký theo |
|---|---|---|
| Text unit | text_unit | Đ29 hoặc cơ chế tương đương hiện hành |
| Component | component | Đ29 hoặc cơ chế tương đương hiện hành |
Đăng ký species/collection mapping theo cơ chế Đ29/Đ0-G hiện hành; thao tác cụ thể thuộc deployment/design.
§2.3 Relation có vào scope L4 không?
Relation/universal_edges nếu đã thuộc governed collection thì dùng birth path hiện hành; L4 không mở rộng relation. Nếu cần siết thêm, xử lý ở design phase.
§3. Birth gate áp cho object nào?
| Object | Có birth gate? | Ghi chú |
|---|---|---|
| Document envelope | Đã có trong Đ0-G hiện hành (normative_registry = governed collection) | Không thay đổi |
| Text unit | Mới — L4 bổ sung | Species text_unit, birth gate kiểm theo §4 |
| Component | Mới — L4 bổ sung | Species component, birth gate kiểm theo §5 |
| Relation | Nếu đã thuộc governed collection thì dùng birth path hiện hành | L4 không mở rộng |
§4. Text unit birth — kiểm gì?
§4.1 Nguyên tắc chung
Text unit birth gate reuse nguyên lý Đ0-G (PEN/STAMP/GATE) + mở rộng theo L1 + L3. Nguyên lý: chặn text unit thiếu metadata vào PG. Thiết kế cơ chế cụ thể (inspector, function) thuộc design phase.
§4.2 Core metadata tối thiểu tại birth
Dựa trên L3 §4.2 (core-equivalent text unit) và L1 (nguyên tắc bắt buộc):
| Nhóm kiểm tra | Nội dung | Nguồn |
|---|---|---|
| Identifier | Canonical address phải có hoặc được cấp bởi system-auto trong birth path; unique theo rule thiết kế | L1 §3.4, §4.3 |
| Thuộc document | doc_code phải trỏ đến document envelope tồn tại và hợp lệ | L1 §3.3 |
| Cây cấu trúc | Parent phải tồn tại + cùng document (nếu không phải root unit). Sort_order phải có giá trị. | L1 §3.5 |
| Content payload | Content payload hợp lệ theo section_type: body hoặc title/heading/structural marker theo profile. Heading/container unit có thể không có body dài. | L1 §4.1, profile config |
| Classification | Section_type phải thuộc controlled vocabulary đã đăng ký | L3 §8.9 |
| Ownership | Owner phải có giá trị | L3 §6.2 |
| Description | Description phải có giá trị (core governance expectation cho text unit) | L3 §4.3 |
| Lifecycle | Status mặc định draft tại birth — system auto | L1 §3.7 |
§4.3 Required profile tại birth
Ngoài core metadata, required profile fields (theo config đăng ký cho section_type/doc_family tương ứng) cũng phải có giá trị tại birth. Danh sách required profile fields = config data, xác định tại design/seed phase (L3 §5.2).
§4.4 Derived fields — KHÔNG kiểm tại birth
Các metadata cấu trúc theo nguyên tắc derived-first (L3 §6.2) như tier, body_hash = system auto hoặc DOT derive sau birth. Birth gate không kiểm các field này.
Ngoại lệ: field system-auto bắt buộc để hoàn tất birth (như status mặc định, canonical address nếu do system cấp) vẫn được xử lý trong birth path — đây là system auto, không phải kiểm tra birth gate.
§5. Component birth — kiểm gì?
§5.1 Nguyên tắc chung
Component birth gate reuse nguyên lý Đ0-G + mở rộng theo L2 + L3. Đặc biệt: component có thêm reuse decision check — không có ở text unit.
§5.2 Core metadata tối thiểu tại birth
Dựa trên L3 §4.2 (core-equivalent component) và L2 (nguyên tắc bắt buộc):
| Nhóm kiểm tra | Nội dung | Nguồn |
|---|---|---|
| Identifier | Code phải có, unique, đúng format | L2 §3.6 |
| Tên + spec | Name + spec_summary phải có giá trị | L2 §3.6 |
| Classification | Component_type phải thuộc controlled vocabulary đã đăng ký | L2 §3.5, L3 §8.9 |
| Ownership | Owner phải có giá trị | L3 §6.2 |
| Description | Description phải có giá trị | L3 §4.3 |
| Interface | Interface/contract summary phải có ở mức governance nếu component type yêu cầu; profile quyết định mức bắt buộc | L2 §3.6 |
| Variant trace | Nếu là variant: base_component phải trỏ đến component tồn tại | L2 §3.7 |
| Lifecycle | Status mặc định draft tại birth — system auto | L2 §3.6 |
§5.3 Reuse decision check
Đây là kiểm tra đặc thù của component, không áp cho text unit.
| Kiểm tra | Nội dung | Nguồn |
|---|---|---|
| Reuse decision record | Tạo component mới theo bước ④ hoặc tạo variant/base mới cần có reuse decision record ghi nhận đã tìm kiếm + justification. | L2 §3.11, §4.2 |
| Human approval | Tạo mới (④) hoặc tạo variant/base mới cần human approval theo L2. Reuse nguyên trạng/cấu hình (①②) không nhất thiết cần approval nếu policy cho phép. | L2 §4.1 |
Component birth chỉ kiểm reuse decision ở mức existence/authority. Không đánh giá chất lượng kiến trúc sâu tại birth — việc đó thuộc review/DOT/council.
Birth path phải kiểm reuse decision. Cơ chế block/warn/escalate xác định ở design phase (L2 §3.11 đã ghi rõ).
§5.4 Required profile tại birth
Tương tự text unit: required profile fields theo config đăng ký cho component_type tương ứng phải có giá trị tại birth.
§6. Enforcement mode
§6.1 Nguyên tắc chung
Enforcement mode = block/warn/escalate theo rule, không hardcode toàn bộ thành reject.
| Mode | Khi nào | Mô tả |
|---|---|---|
| Block | Mặc định cho object mới nếu không có ngoại lệ hợp lệ | Birth không hoàn tất/certify. Object bị route sang trạng thái xử lý theo rule. |
| Warn | Khi rule cho phép (VD: optional profile thiếu, hoặc governance decision cho phép) | Object vào PG + cảnh báo, DOT daily sẽ theo dõi |
| Escalate | Khi cần human judgment | Object chờ approval trước khi hoàn tất birth |
§6.2 Config-driven enforcement
Mode nào áp cho kiểm tra nào = config data, không hardcode trong phụ lục pháp lý. Nguyên tắc: core metadata thiếu → mặc định block. Required profile thiếu → mặc định block. Optional profile thiếu → warn. Governance decision có thể override mặc định theo rule đã đăng ký.
§7. Ngoại lệ, legacy, migration
§7.1 Legacy entities
Entities tạo trước khi L4 có hiệu lực (predated birth gate) sẽ không pass birth gate nếu chạy lại. Xử lý:
- Backfill: DOT quét legacy entities, bổ sung metadata thiếu nếu có thể derive.
- Grandfather rule: entities đã enacted/active trước ngày hiệu lực L4 được miễn birth gate retrospective. DOT daily vẫn kiểm correctness/consistency (L3 §7.2/§7.3).
- Grandfather rule không miễn correctness/consistency và không miễn khi tạo version mới. Version mới của legacy entity phải qua birth gate đầy đủ.
- Danh sách legacy entities cần backfill = audit output, không hardcode.
§7.2 Migration path
Migration plan chi tiết thuộc design phase (C7). L4 chỉ chốt nguyên tắc:
- Legacy không bị reject bởi birth gate retrospective.
- Legacy vẫn bị DOT daily kiểm.
- Backfill theo khả năng, không bắt buộc 100% ngay.
§7.3 Ngoại lệ runtime
Ngoại lệ birth gate (VD: entity tạo bởi system migration, emergency insert) phải có approval record. Approval record ghi: ai approve, lý do, thời hạn ngoại lệ (nếu có). Agent không tự tạo ngoại lệ — phải có human authority.
§8. Quan hệ với Đ0-G hiện hành
§8.1 Không thay đổi gì ở Đ0-G
| Giữ nguyên | Lý do |
|---|---|
| birth_registry schema lõi | Đã proven. L4 chỉ thêm species mới vào scope. Nếu cần schema change phải amend Đ0-G riêng. |
| Inspector pipeline (PEN/STAMP/GATE) | Cơ chế đã proven. Text unit + component sẽ có inspectors riêng thiết kế ở design phase, nhưng nguyên lý pipeline giữ nguyên. |
| Auto-certify mechanism | Giữ nguyên. Text unit + component certified khi tất cả inspectors pass. |
| Write path pattern | Giữ nguyên nguyên lý. Write path cho text_unit/component sẽ được nối vào birth pipeline ở deployment/design. |
§8.2 Bổ sung gì?
| Bổ sung | Mô tả |
|---|---|
| Species text_unit + component | Đăng ký species/collection mapping theo cơ chế Đ29/Đ0-G hiện hành; thao tác cụ thể thuộc deployment/design |
| Birth gate check mở rộng cho 2 species | Core metadata + required profile + reuse decision (component only) |
| Enforcement mode config | Block/warn/escalate theo rule thay vì chỉ certified/uncertified |
§9. Nguyên tắc bắt buộc
| # | Nguyên tắc | Cơ sở |
|---|---|---|
| 1 | Mọi text unit và component mới phải qua birth gate. Không có đường tắt vào PG mà bỏ qua birth gate. | Đ0-G nguyên tắc gốc, L1 §4.8, L2 §4.7 |
| 2 | Birth gate kiểm completeness, không kiểm correctness. Correctness thuộc DOT daily (L3 §7.2). Review/approval nội dung thuộc L5/Đ32. | L3 §7.1 vs §7.2 |
| 3 | Reuse decision bắt buộc cho component birth (tạo mới/variant/base mới). Reuse nguyên trạng/cấu hình theo policy. Không áp cho text unit. | L2 §3.11, §4.1-§4.2 |
| 4 | Enforcement mode = config-driven. Block/warn/escalate theo rule, không hardcode. | L3 §6, §8.4 |
| 5 | Legacy entities miễn birth gate retrospective, không miễn correctness/consistency, không miễn version mới. DOT daily vẫn kiểm. | Nguyên tắc non-retroactive |
| 6 | Ngoại lệ runtime phải có human approval record. Agent không tự tạo ngoại lệ. | Đ32, L2 §4.8 |
| 7 | Derived fields không kiểm tại birth. Tier, hash, counts = system auto/DOT derive sau birth. Trừ field system-auto bắt buộc hoàn tất birth. | L3 §6.2, §7.1 |
| 8 | Reuse nguyên lý Đ0-G, không copy nguyên trạng. PEN/STAMP/GATE là mô hình tham chiếu. Text unit + component inspectors thiết kế mới theo scope mới. | 02DY |
| 9 | Component birth chỉ kiểm reuse decision ở mức existence/authority. Không đánh giá chất lượng kiến trúc sâu tại birth. | L2, Đ32 |
§10. Ranh giới — không làm gì trong phụ lục này
| Không làm | Lý do |
|---|---|
| Không thay đổi birth_registry schema | Giữ nguyên Đ0-G. Nếu cần mở rộng schema = amend Đ0-G riêng. |
| Không viết trigger/function/DOT list cụ thể | Implementation thuộc design phase |
| Không chốt tên inspector cụ thể | Design phase quyết định inspector nào, kiểm gì |
| Không chốt migration plan chi tiết | Thuộc C7 |
| Không định nghĩa lại text unit / component / metadata | Thuộc L1, L2, L3 |
| Không chốt thứ tự inspectors cho species mới | Design phase có thể tối ưu thứ tự khác |
| Không chốt quarantine/rejected storage model | Thuộc design phase |
§11. Liên kết với luật hiện hành
| Luật | Quan hệ |
|---|---|
| Đ0-G v1.0 | L4 mở rộng scope, giữ nguyên cơ chế lõi. Không thay đổi schema Đ0-G. |
| L1 (Text Unit) | L4 chốt birth gate cho text_unit dựa trên core metadata L1 |
| L2 (Component/BOM) | L4 chốt birth gate cho component + reuse decision check dựa trên L2 |
| L3 (Metadata) | L4 dùng core metadata + required profile + enforcement mode từ L3 |
| Đ4 (Lifecycle) | Status mặc định draft tại birth |
| Đ29 (Species) | text_unit + component đăng ký species theo cơ chế hiện hành |
| Đ32 (Approval) | Ngoại lệ birth gate cần human approval. Review/approval nội dung thuộc Đ32/L5. |
| HP NT2 | Birth gate = cơ chế máy |
| HP NT11 | Chỉ kiểm metadata PG không tự biết |
| 02DY | Reuse nguyên lý birth gate (Fix 27-28), không copy |
§12. Điều kiện PASS
| # | Điều kiện |
|---|---|
| 1 | Scope mở rộng rõ ràng: text_unit + component vào birth gate |
| 2 | Birth check cho text_unit nhất quán với L1 + L3 |
| 3 | Birth check cho component nhất quán với L2 + L3, bao gồm reuse decision |
| 4 | Enforcement mode config-driven, không hardcode |
| 5 | Legacy/migration xử lý bằng rule, không retroactive, version mới phải qua birth gate |
| 6 | Không thay đổi cơ chế lõi và schema Đ0-G |
| 7 | Không trượt sang schema/trigger/DOT list/migration plan |
| 8 | L4 đủ làm tiền đề cho design phase birth gate implementation |
| 9 | Council review + User duyệt |
DỰ THẢO | L4 Mở rộng Đ0-G — Birth Gate cho Text Unit + Component | GPT review: PASS, 12 chỉnh + 3 khuyến nghị đã áp dụng | Chờ Council + User