Council Review — GPT — Điều 28 v2.0 + HP v4.2.0

Căn cứ đọc

• knowledge/dev/architecture/dieu28-display-technology-law-v2-draft.md
• knowledge/dev/laws/constitution-v4.2.0-amendment-draft.md
• knowledge/dev/laws/constitution.md
• knowledge/dev/ssot/anti-patterns.md
• knowledge/dev/ssot/operating-rules.md
• knowledge/dev/architecture/standard-template-law.md

A. Điều 28 v2.0

A1: CÓ — Tuyên bố "Nuxt chỉ render từ khuôn đã đăng ký trong PG" rất rõ và đi đúng gốc của NT6 + AP-11. Nó chặn thói quen sáng tác page/component mới cho từng collection. Tuy nhiên để giải quyết VĨNH VIỄN thì chưa đủ chỉ tuyên bố; phải có enforce kỹ thuật ở runtime, CI, DOT scan và registry-coverage. Nếu không, agent vẫn có thể tạo component mới rồi route riêng ngoài whitelist.

A2: CÓ — 5 nguyên tắc riêng nhìn chung không xung đột Hiến pháp, mà còn siết NT4, NT6, NT8 và dự thảo NT10 chặt hơn. Điểm cần sửa là câu "Nuxt ĐƯỢC LÀM: nhận user input → gửi về Directus API" dễ bị hiểu lỏng thành Nuxt tự điều phối logic submit phức tạp. Nên ghi rõ Nuxt chỉ phát event/submit payload; validation nghiệp vụ, transition và side effects phải nằm ở PG/Directus/DOT.

A3: KHÔNG — Schema design_templates chưa đủ để quản trị khuôn ở mức vận hành lớn. Thiếu tối thiểu: version, is_active/effective_from, deprecation_note, owner_dot, render_contract, data_contract, allowed_collections hoặc scope_rules, error_codes, rollback_template_code, performance_budget, permissions_profile, created_by_dot/run_id, updated_at, activated_at. Thiếu ràng buộc quan trọng giữa template và instance: mỗi instance phải tham chiếu template_code FK sống, và cần cấm instance dùng template deprecated/retired. Thừa nhẹ: component_path là cần, nhưng nếu không khóa bằng whitelist generated từ PG thì chỉ là text tự khai.

A4: KHÔNG — Checklist 8 bộ phận tốt nhưng chưa chặn hết lỗi khuôn. Thiếu ít nhất 4 bộ phận: (1) contract dữ liệu đầu vào/đầu ra có version; (2) observability/metrics + log signature để DOT-health biết lỗi gì; (3) permission & scope check để template không lộ field ngoài quyền; (4) rollout/rollback plan khi activate template đang có nhiều instance. Documentation và birth record là cần, nhưng không thay thế được các chốt vận hành này.

A5: KHÔNG — 5 loại test cover phần lõi nhưng PASS/FAIL chưa đủ chặt để vận hành tự động. Thiếu test tương thích ngược khi sửa template/config_schema; thiếu test phân quyền; thiếu test hiệu năng; thiếu test migration/backfill cho component chuyển giao; thiếu test concurrency khi nhiều instance/config cập nhật cùng lúc; thiếu test registry truth: template active nhưng component_path không tồn tại hoặc không nằm whitelist build. Test 4 "1 ô sai = fail" đúng tinh thần NT9, nhưng phải quy định bộ dữ liệu kiểm chứng, snapshot nguồn thật và DOT nào chạy thì mới đo được.

A6: KHÔNG — Section VI đúng hướng nhưng 4 tiêu chí hiện tại còn thiếu 2 tiêu chí quan trọng: (a) khả năng quy về 1 contract hiển thị ổn định, (b) khả năng enforce bằng PG/Directus mà không lén giữ logic trong component. Quy trình 5 bước cũng thiếu bước quyết định "không nên template hóa" để tránh nhét mọi thứ vào khuôn. Bảng ứng viên còn thiếu rõ ràng các nhóm thường gặp như timeline/activity feed, attachment/file viewer, relation graph, approval history, audit log, form renderer/read-only detail sections, status badges/summary cards. Đồng thời BirthTrigger không nên đứng trong whitelist như một template hiển thị; đó là cơ chế hạ tầng, không phải UI template.

A7: KHÔNG — Cơ chế whitelist hiện mô tả được ý tưởng nhưng chưa đủ enforce. Lỗ hổng bypass gồm: route import component trực tiếp; dynamic import từ path không qua registry; page riêng hardcode component; component wrapper chung nhưng bên trong switch-case theo string không đối chiếu DB; template code active nhưng component file bị đổi nghĩa; build bundle vẫn chứa component cấm. Cần 4 chốt cùng lúc: whitelist runtime từ PG, manifest build-time generated, scanner CI quét mọi import của components/templates, và DOT/contract check so route thực tế với registry.

A8: CÓ, NHƯNG — Về kiến trúc dữ liệu thì 100+ khuôn và 10,000+ instances chịu được nếu config/query chuẩn vì PG + Directus xử lý quy mô này không khó. Điểm nghẽn sẽ nằm ở template health, truth check diện rộng, và config JSONB không chuẩn hóa. Nếu mọi template đều dùng JSONB tự do thì scale quản trị sẽ gãy: khó index, khó audit, khó matrix. Muốn chịu tải thật phải có taxonomy khuôn, contract versioning, index cho field hay lọc, cache policy rõ, và DOT-health chạy phân tầng theo risk thay vì quét ngây thơ toàn bộ mỗi lần.

B. NT10

B1: Định nghĩa hiện khá rõ về hướng nhưng vẫn có thể bị hiểu nhầm. Câu đúng phải là: "Thông tin nào cần cho máy validate, query, enforce, tự động thao tác hoặc ra quyết định thì phải có representation có cấu trúc trong PG; text chỉ để giải thích cho người." Nếu viết quá ngắn, agent có thể hiểu sai thành "mọi thứ đều phải nhét vào PG", kể cả narrative docs.

B2: Phạm vi hiện hơi rộng ở câu khẩu hiệu, nhưng phần giải thích đã tự thu hẹp đúng hơn. Nên có ngoại lệ rõ: text được phép giữ vai trò giải thích, quyết định hội đồng, rationale kiến trúc, postmortem, hướng dẫn thao tác, prompt. Không cần ép toàn bộ prose vào PG. Cái bắt buộc vào PG là operational metadata, machine rules, config, trạng thái, mapping, approval, contract, registry. Ngoại lệ hợp lệ duy nhất: thông tin chưa có mô hình dữ liệu chín, chỉ đang ở giai đoạn khám phá; khi đó text là tạm thời và phải có ticket chuyển hóa.

B3: NT10 không mâu thuẫn NT1-9; ngược lại còn làm NT1, NT2, NT3, NT4, NT6, NT8 mạnh hơn. Xung đột chỉ xảy ra nếu áp dụng cực đoan kiểu biến cả tài liệu giải thích thành DB rows. Như vậy sẽ phản tác dụng với NT1 vì SSOT bị vỡ thành data vô nghĩa và khó đọc.

B4: Có. Một số thứ đang ở text mà chưa thể hoặc chưa nên chuyển hết sang PG ngay: rationale dài, tranh luận hội đồng, prompt tác vụ, playbook điều tra sự cố, narrative postmortem, so sánh phương án kiến trúc. Giới hạn kỹ thuật không phải vì PG không chứa được text, mà vì chưa có schema ổn định để máy dùng hữu ích. Phải tách rõ: text tri thức vẫn ở Agent Data; phần máy cần enforce thì sinh ra collection/field tương ứng trong PG.

C. Tổng thể

C1: Lỗ hổng lớn nhất là "template active nhưng không chứng minh được coverage toàn hệ thống". Luật chưa bắt buộc một báo cáo machine-generated trả lời 3 câu: (1) mọi business-data UI route hiện do template nào render; (2) route nào còn ngoài registry; (3) component nào còn import trực tiếp ngoài whitelist. Không có coverage report này thì vẫn còn vùng tối. Lỗ hổng thứ hai là sửa template gây phá instance cũ nhưng luật chưa có compatibility matrix/semver.

C2: Over-engineering nằm ở chỗ dùng 1 collection design_templates gánh quá nhiều vai trò nhưng chưa tách lớp. Nếu nhồi cả schema, checklist, test results, migration, docs, health vào 1 record JSONB lớn thì về sau audit khó. Nên đơn giản theo hướng: design_templates (định danh + contract lõi), design_template_tests, design_template_health, design_template_migrations, design_template_instances hoặc ít nhất chuẩn hóa JSONB theo sub-schema có version. Ngoài ra, không nên template hóa các hạ tầng như BirthTrigger/Layout vào cùng whitelist hiển thị.

C3: Thiếu 6 điểm quan trọng: (1) versioning + backward compatibility policy; (2) permissions/sensitive-field policy; (3) rollout/rollback/canary khi activate template; (4) registry coverage scanner bắt component/route tự do; (5) performance budget + query budget; (6) quy định rõ ranh giới giữa display template và workflow/input template để Nuxt không lén mang logic nghiệp vụ trở lại.

C4: Điểm 7.0/10

Khuyến nghị cụ thể

• Bổ sung điều khoản ENFORCEMENT: route chỉ được render từ manifest whitelist sinh từ PG + CI scanner cấm import ngoài components/templates.
• Bổ sung versioning cho template và config_schema; cấm sửa phá vỡ instance active nếu chưa có migration/compatibility policy.
• Tách rõ 3 lớp: display template, infra component, business workflow/input orchestration. Chỉ lớp 1 mới thuộc Điều 28.
• Bổ sung check permissions, performance, observability vào checklist/test bắt buộc.
• Thêm machine-generated coverage report: "toàn bộ business UI đã nằm trong design_templates chưa?" Đây là chốt để nói giải quyết VĨNH VIỄN.
• Sửa NT10 thành định nghĩa chính xác hơn: cái gì máy cần validate/query/enforce thì phải có representation trong PG; text chỉ là documentation/rationale.
• Giữ nguyên hạt nhân đúng của Điều 28: Nuxt chỉ render từ khuôn đăng ký trong PG; instance mới = INSERT config; không có khuôn = không có giao diện.
• Giữ nguyên hướng NT10 vì nó đóng đúng lỗ hổng "quản lý bằng text" và củng cố NT6 + NT8.