02 — Điều 45 Draft — Mirror + Drafting Notes

Date: 2026-05-26 Đây là tài liệu HỖ TRỢ — không phải luật. Luật chính ở knowledge/dev/laws/dieu45-pg-native-queue-and-task-orchestration-law.md. Mục đích: ghi rõ chú thích drafting, lý do chọn cấu trúc, dấu vết quyết định cho Council reviewer.

§1. Source materials chính

Survey reports knowledge/dev/laws/dieu44-trien-khai/v0.6-system-wide-pg-native-queue-law-readiness-survey/ 00–08 (PASS 2026-05-26).
GPT proposal trong mission prompt (2026-05-26): 20 sections, queue principles, compatibility list, PG16/PG18 clause.
Live PG inventory — verified read-only:
- event_outbox 131,746 rows + CHECK constraints.
- event_type_registry 31 rows × 4 active domains.
- event_subscription 3 rows.
- iu_route_worker_cursor 1 row (iu_outbound_default).
- iu_route_dead_letter 0 rows (schema ready).
- iu_sql_event_route 1 dry-run row.
- dot_iu_runtime_lease 0 rows (acquire/release fns).
- iu_core.iu_staging_record/payload (7-state lifecycle).
- iu_auto_instantiate_event_log 33 idempotent rows.
Existing laws (cross-referenced):
- Điều 31 v1.2 BAN HÀNH 2026-03-22 (System Integrity, watchdog, refusal).
- Điều 35 v5.2 FINAL BAN HÀNH 2026-04-18 (DOT Governance, ADMIN fallback).
- Điều 36 v5.0 DRAFT 30% (Collection Protocol, NVSZ design).
- Điều 37 v3.3 BAN HÀNH 2026-04-01 (Governance Organization, agency/role).
- Điều 30 v1.1 BAN HÀNH 2026-03-22 (Regression Protection).
- Điều 44 v0.1.2 controlled DRAFT (IU-0 Implementation).
Design docs:
- 23-P3D4C0X rev1 (Universal Event/Outbox 5-layer architecture).
- 23-P3D4C1 rev3 (Staging outbox + worker prompt — paused).
- 23-P3D4C1U rev7 (Universal core implementation — awaiting dispatch).

§2. Drafting decisions log

Decision	Choice	Why
Sections count	22 (vs GPT 20)	+§0 Executive Summary (pattern law hiện hành) + §22 Verification Block (pattern enacted laws)
Language	Vietnamese body + English technical terms	Đồng nhất với D31/D35/D37 enacted laws
Vocab table	CHECK-cứng từ live PG	Ratify what's already enforced — minimum amend
Inclusion criteria 7+7	Port từ `23-P3D4C0X §M.3`	Rubric is mature; ratifying it now prevents queue-as-activity-log creep
Customer-care/email	Design seam (not normative P1)	No substrate exists; codifying speculative is anti-pattern (Điều 18.1)
`pg_cron`	§5.4 explicit boundary — out at P1, can be opted in via amendment	Survey D1 decision is unanswered
`max_attempts`	Mở (§8.1 không ấn định)	Survey D4 unanswered; let DP3 decide with empirical data
14 hard-reject anti-patterns	Explicit table §17	Without explicit anti-patterns, refusal contract is fuzzy
Compatibility matrix	YAML block §16.1	Cross-referenceable; review-friendly
Transitional §20	Lists every live substrate row count	Reviewer can verify "ratify what's there" claim
Version block §22	50+ verification keys	Pattern from enacted laws

§3. Câu hỏi reviewer có thể hỏi — pre-answered

§3.1 "Điều 45 quá dài (~32k chars) — có thể nén?"

Có. Nhưng:

Điều 31 hiện hành = ~38k chars.
Điều 35 hiện hành = ~37k chars.
Điều 37 hiện hành = ~20k chars.
32k chars cho luật ratify 8 nguyên tắc + 22 sections × ratify substrate hiện hành = trong khoảng chấp nhận.

Có thể nén:

§6 vocab tables thành reference.
§17 anti-patterns thành chỉ chữ (mất searchability).
§20 transitional clause (giảm chi tiết row count).

Không khuyến nghị nén tại v0.1 — sau Council review nếu Council yêu cầu thì nén.

§3.2 "§13 customer-care/email là forward-compatible — sao đặt trong luật?"

Có 2 lý do:

Mission yêu cầu (mission prompt liệt kê customer-care/email/MOT).
Forward-compatibility clause (§13.2) là một invariant về cách mở rộng — không phải invariant về substrate.

Nếu bỏ §13: tương lai khi mở customer-care, không có guidance — nguy cơ ngoài-luật. Giữ §13 ở dạng seam (không codify substrate) đáp ứng cả mission yêu cầu lẫn nguyên tắc "không codify speculatively".

§3.3 "Tại sao §11 phân ranh ba lớp — không quá nghiêm khắc?"

Lý do nghiêm khắc:

Substrate hiện hành đã mix: fn_iu_collection_create (producer) gọi fn_iu_emit_collection_event (queue interface) — chấp nhận (§11.4).
Nhưng nếu cho phép producer gọi consumer business trong cùng transaction → khó debug, hard to rollback, racing risk.
§11 phân ranh giúp design pack tương lai rõ "hàm này thuộc layer nào".

Không quá nghiêm khắc vì §11.4 cho phép producer + emit cùng process.

§3.4 "Vì sao không có §X về sharding/partitioning?"

Đã đặt trong §15 risk register (event_outbox > 5M rows). Partitioning là implementation detail (DP7 §18.4), không là invariant luật. Luật chỉ phát biểu requirement quan sát.

§3.5 "Tại sao chấp nhận `iu_*` function name prefix khi luật system-wide?"

§3.3 + §20.2 thừa nhận: tên hàm là lịch sử triển khai, không phải scope. Đổi tên là risk migration (consumers, START-HERE references, DOT registry). Phase 1 KHÔNG đổi tên. Sub-design pack tương lai có thể alias fn_queue_* → fn_iu_* mà giữ compat.

§3.6 "§14 nâng D36 NVSZ lên luật — D36 có agree không?"

D36 hiện ở DRAFT 30%. NVSZ Macro A đã APPLIED (2026-05-25) — production-proven. Điều 45 ratify implementation đó.

Nếu D36 BAN HÀNH sau Điều 45: phải có cross-reference ngược (D36 references D45 §14). Quyết định coordination này thuộc Council.

§3.7 "§8.5 'refusal contract' vs D31 'refusal' — có conflict?"

Không. D31 §X (refusal contract) ở mức system contract. Điều 45 §8.5 áp dụng cụ thể cho queue worker. Pattern đồng nhất, không trùng lặp.

§4. Risk register cho law text

Risk	Mức	Mitigation
Council yêu cầu rename §0/§1 ordering	Low	Trivial edit
Council yêu cầu xoá §13 (out of P1 scope)	Low	Có thể chấp nhận, nhưng mất forward-compatibility clause
Council yêu cầu ấn định `max_attempts` cụ thể	Medium	Defer to DP3; reject if Council insists w/o data
Council yêu cầu `pg_cron` adoption ngay	Medium	Refuse — D1 chưa quyết định; ép vào law tạo speculative invariant
Council yêu cầu thêm sharding clause	Low	Add §15.X partitioning when threshold
Gemini yêu cầu Pub/Sub clone reframing	Low	Đã reframe; nếu vẫn yêu cầu thì thêm explicit anti-pattern row §17
User yêu cầu Vietnamese-only (no English terms)	Medium	Reject — technical terms (event_outbox, idempotency, payload_ref, ...) không nên dịch

§5. Diff vs GPT proposal — chi tiết

GPT proposal có 20 mục:

1. Purpose and scope
2. Definitions (queue/event/job/task/message/worker/lease/dead-letter/trigger-in/trigger-out/payload_ref)
3. System-wide applicability
4. Queue carries signal, not data
5. PG-native architecture principles
6. Lifecycle/status vocabulary
7. Idempotency and deduplication
8. Retry, lease, and dead-letter
9. Scheduling and delayed execution
10. Batch processing
11. Worker / Agent / DOT / Hermes executor boundary
12. Trigger-in / trigger-out for Information Units
13. Customer-care / email / messaging future scope
14. No-vector transient payload rule
15. Observability, audit, and healthcheck
16. Compatibility with existing laws
17. Prohibited patterns
18. Implementation discipline
19. Open design questions before implementation
20. Transitional clause for existing event_outbox substrate

Claude draft 22 sections — diff:

GPT mục	Claude mục	Status
(none)	§0 Tóm tắt điều hành	ADDED (pattern enacted laws)
1	§1 Mục đích + phạm vi	OK
2	§2 Định nghĩa (14 terms, GPT đề xuất 10–11)	EXPANDED
3	§3 Áp dụng hệ thống	OK
4	§4 Signal not data	OK
5	§5 PG-native principles	OK + pg_cron clause §5.4
6	§6 Vocab vòng đời + Inclusion criteria	EXPANDED (+§6.4 rubric 7+7)
7	§7 Idempotency	OK + 3-layer defense
8	§8 Retry/lease/dead-letter	OK + §8.5 refusal contract
9	§9 Scheduling	OK + no-pg_cron clause §9.4
10	§10 Batch	OK
11	§11 Executor boundary	EXPANDED (3-layer ASCII diagram)
12	§12 Trigger-in/Trigger-out	OK + §12.3 IU two-way concrete
13	§13 Customer-care/email/MOT	SOFTENED to design seam (Claude diff)
14	§14 No-vector	EXPANDED (4-layer guarantee ratify)
15	§15 Observability	EXPANDED (+§15.4 liveness contract)
16	§16 Compatibility	EXPANDED (YAML matrix)
17	§17 Prohibited patterns	EXPANDED (14 hard-reject + 3 soft-warn table)
18	§18 Implementation discipline	EXPANDED (+§18.4 7 sub-design packs)
19	§19 Open questions	EXPANDED (21/28 routed)
20	§20 Transitional clause	EXPANDED (row-by-row inventory)
(none)	§21 Cross-reference 13 laws	ADDED
(none)	§22 Verification block	ADDED (pattern enacted laws)

Tổng cộng: 3 mục thêm, 0 mục bác bỏ, 20/20 mục GPT giữ, 8 mục mở rộng đáng kể, 1 mục mềm hoá (§13).

§6. Câu chữ Vietnamese — note

"Hàng đợi" = queue.
"Điều phối tác vụ" = task orchestration.
"Tín hiệu" = signal (vs "data" = dữ liệu).
"Vòng đời" = lifecycle.
"Người thực thi" / "executor" = giữ song ngữ vì là layer khái niệm.
"Bất biến" = invariant.
"Không xâm phạm" = non-interfering.
"Chuyển tiếp" = transitional.

Một số technical terms KHÔNG dịch:

event_outbox, event_pending, event_read, event_subscription, event_type_registry.
iu_route_*, dot_iu_command_run, dot_iu_runtime_lease.
safe_payload, payload_ref, correlation_id, idempotency_key, lease_token.
pg_cron, pg_notify, LISTEN/NOTIFY, SKIP LOCKED.

§7. File metadata

Law file path: knowledge/dev/laws/dieu45-pg-native-queue-and-task-orchestration-law.md
File size: ~32 KB
Sections: 22
Tables: 13+ (vocab, compatibility, anti-patterns, executor mapping, transitional rows)
Cross-references: 13 laws + 6 design docs + 8 sub-design packs proposed
Verification keys: 50+

§8. Self-critique

Điểm Claude tự đánh giá chưa hoàn thiện:

§6 Vocab tables nhiều hơn cần thiết — có thể move sang appendix sau Council review.
§17 Anti-patterns table có thể trùng lặp với §4 / §5 / §11. Đã cố gắng tránh nhưng review reviewer.
§20.4 Worker silent gap — phát biểu nhưng không resolve gap. Đẩy sang Q25 §19. Reviewer có thể yêu cầu action plan ngay.
§13 forward-compatibility — softened theo Claude judgement. Reviewer có thể yêu cầu cứng hơn (codify customer/email/MOT vocab) hoặc xoá sạch (chỉ luật scope hiện hành). Đợi feedback.
Tiếng Việt — Claude là LLM, có thể có lỗi diễn đạt. Một số chỗ Vietnamese chưa idiomatic. Reviewer có thể đề xuất rewording.

Không có mục nào Claude tự thấy sai về invariant.