Council Review Đ43 v1.2 DRAFT — Round 1 — GPT

Date: 2026-04-17 Reviewer: GPT Score: 6.9/10 Recommendation: APPROVE WITH CHANGES

Q1 — Xung đột luật

Kết luận tổng

XUNG ĐỘT NHẸ, không thấy xung đột nghiêm trọng bắt buộc amend luật khác.

1) Với HP v4.6.1

• Hướng amend v1.2 là đúng tinh thần HP: chuyển hardcode sang reference table PG + dot_config để tiến gần hơn NT2 / NT4 / NT10 / NT11.
• Tuy nhiên v1.2 chưa đóng trọn mục tiêu HP vì vẫn còn 2 chỗ hardcode/logic cứng quan trọng:
  1. context_pack_manifest.section_count đang giữ ràng buộc cứng = 8 (kế thừa v1.1 §5.3)
  2. context_pack_health_checks.check_type vẫn là enum cứng 9 loại, và draft tự thừa nhận thêm H10 kiểu mới sẽ phải amend verify.sh
• Vì vậy, v1.2 đi đúng hướng nhưng chưa đạt trạng thái “tuân thủ hoàn toàn NT2 + NT4 + NT11”.

2) Với Đ33 v2.0

• Không thấy vi phạm nghiêm trọng.
• Bootstrap bằng migration/table seed vẫn nằm trong ngoại lệ hợp pháp của NT3 theo Đ33 §13.
• Việc thêm reference tables và dot_config keys là thay đổi ở PG-first layer, phù hợp Đ33 §14–§15 hơn là xung đột với chúng.

3) Với Đ35 v5.1

• Không xung đột nghiêm trọng.
• 2 DOT cặp build/verify vẫn giữ đúng precedent paired_dot, trigger_type, coverage_status, extra_metadata, và nguyên tắc CẤM POST partial row.
• Retry mới trong context_pack_requests không đụng Đ35 vì đây là queue nội bộ của Đ43, không phải payload dot_tools 11 fields.
• Điểm cần lưu ý: nếu retry logic ở Bước 8 tự đưa request từ failed về pending, implementation phải vẫn log issue/APR đúng ngưỡng để không mâu thuẫn tinh thần Đ35 + Đ22 về escalation.

4) Với Đ36 v4.0 Collection Protocol

• Không thấy xung đột trực tiếp.
• Đ43 vẫn đọc snapshot hạ tầng/system map; không ghi đè hay thay vai trò Collection Protocol.
• Không thấy nhu cầu amend Đ36 chỉ vì v1.2.

5) Với Đ41 v1.0 VPS-as-SSOT

• Không xung đột.
• v1.2 giữ nguyên guard quan trọng của v1.1: on-deploy chỉ fire sau Đ41 Bước 6.5 is_known_good=true.
• Việc scan paths từ config còn giúp thích nghi hơn với thay đổi layout VPS, nên nhìn chung còn hợp Đ41 hơn v1.1.

6) Với Đ38 v2.3 Văn bản Quy phạm

• Không thấy xung đột.
• v1.2 vẫn là amend kỹ thuật có changelog rõ, không phá format văn bản quy phạm.
• Việc đưa template ra template_kb_path còn hợp tinh thần tách luật ổn định / phụ lục sống.

7) Với Đ22 Self-Healing

• Xung đột nhẹ mức wording/ranh giới, không nghiêm trọng.
• Retry policy mới là hợp tinh thần NT5 + Đ22, nhưng currently mới dừng ở queue retry; cần bảo đảm escalation rõ: retry hết số lần thì bắt buộc fn_log_issue + APR, không retry vô hạn.
• Draft §6 Bước 8 đã nói vậy, nên hiện tại là ổn về hướng, chỉ cần implementation kỷ luật.

Tóm lại Q1: Không cần amend luật khác. Nhưng v1.2 vẫn còn 2 điểm làm nó chưa thể tự tin nói đã sạch toàn bộ vi phạm HP.

Q2 — Đủ NT2+NT4+NT11?

Test 1: Thêm database thứ 4 analytics vào cụm PG.
PASS — Vì §6 Bước 3 đã đổi sang: nếu context_pack_scan_db_whitelist rỗng thì đếm từ pg_database catalog, không hardcode số 3. Với cụm có thêm analytics, script có thể tự thấy DB mới mà không sửa code, không amend Đ43.

Test 2: Thêm folder code thứ 5 /opt/incomex/mcp-servers/ vào scan scope.
PASS — Chỉ cần UPDATE dot_config SET value=... WHERE key='context_pack_scan_paths'. Không cần sửa code và không cần amend Đ43.

Test 3: Thêm law pattern mới, ví dụ watch cả knowledge/dev/ssot/anti-patterns.md.
PASS — context_pack_watched_key_patterns đã đưa pattern ra config. Chỉ cần UPDATE JSON array, không cần sửa code, không cần amend luật.

Test 4: Thêm section thứ 9 MCP_SERVERS.md.
FAIL — Có 2 lý do:

1. context_pack_manifest ở §5.3 vẫn giữ section_count INT NOT NULL CHECK (section_count = 8) từ v1.1, nên thêm section thứ 9 sẽ vướng schema ngay.
2. context_pack_section_definitions mới chỉ mô tả metadata render (format, template_kb_path, data_source) nhưng chưa có trường đủ để chỉ định truy vấn/nguồn dữ liệu cụ thể cho section mới. Thêm một row chưa đủ đảm bảo script biết lấy data gì để render MCP_SERVERS.md mà không sửa code.

=> Với test này, v1.2 chưa đạt NT2 + NT4.

Test 5: Thêm health check H10 “số lượng DOT active > threshold”.
FAIL — Ngay trong §9 draft đã ghi rõ: nếu check_type mới chưa có handler trong verify.sh thì phải amend verify.sh 1 lần. Điều này có nghĩa là thêm loại health check mới vẫn đòi sửa code, trái mục tiêu test đề ra. Thêm nữa, context_pack_health_checks.check_type đang là CHECK enum cứng 9 loại, nên H10 kiểu mới có thể còn đòi sửa cả schema/law, không chỉ INSERT row.

Tóm tắt 5 test

• Test 1: PASS
• Test 2: PASS
• Test 3: PASS
• Test 4: FAIL
• Test 5: FAIL

=> 3/5 PASS. Theo rubric prompt, đây là mức APPROVE WITH CHANGES chứ chưa phải minor/final.

Q3 — Điểm hardcode sót

1) context_pack_manifest.section_count = 8 — SÓT, mức HIGH

Đây là điểm sót rõ nhất. v1.2 đã chuyển sections sang reference table nhưng manifest vẫn khóa cứng 8 section.

Tác động:

• Chặn trực tiếp Test 4
• Làm toàn bộ lời hứa “thêm section mới chỉ cần INSERT row” không còn đúng

Đề xuất fix:

• Bỏ CHECK section_count = 8
• Thay bằng section_count > 0
• Hoặc tốt hơn: bỏ cột section_count khỏi contract cứng và derive bằng COUNT(*) FROM context_pack_sections WHERE manifest_id = ...

2) context_pack_health_checks.check_type enum cứng 9 loại — SÓT, mức HIGH

Reference table mới chỉ data-driven một nửa; loại check mới vẫn không data-driven thật.

Tác động:

• Chặn trực tiếp Test 5
• Vẫn còn anti-pattern “muốn mở rộng thì sửa code verify”

Đề xuất fix (2 mức):

• Mức tối thiểu: chấp nhận đây là ngoại lệ có chủ đích và ghi rõ trong luật rằng check_type extension là boundary logic-code, không thuộc scope NT4. Nếu chọn hướng này thì Q2 Test 5 phải thành PARTIAL chứ không thể claim PASS.
• Mức đúng tinh thần v1.2 hơn: thêm cơ chế generic, ví dụ:
  • check_executor_type = 'builtin' | 'sql' | 'function'
  • executor_ref hoặc sql_template_kb_path
  • với H10 kiểu count threshold có thể chạy bằng SQL/function config, không cần sửa verify.sh

3) Thiếu cấu hình nguồn dữ liệu/render thực cho section definitions — SÓT, mức HIGH

context_pack_section_definitions hiện có data_source nhưng chưa có field để chỉ rõ query nào / function nào / source path nào tạo ra section đó.

Tác động:

• Thêm section mới bằng INSERT row chưa đủ để script render thật
• template_kb_path mới giải quyết lớp template, chưa giải quyết lớp data binding

Đề xuất fix: Bổ sung ít nhất 1 trong các trường sau:

source_ref TEXT,
query_kb_path TEXT,
render_config JSONB NOT NULL DEFAULT '{}'

Trong đó:

• query_kb_path trỏ KB doc chứa SQL/template query
• hoặc source_ref trỏ function/view chuẩn
• render_config chứa binding info

4) Grace period vẫn đang viết cứng 7 ngày — SÓT MINOR

Prompt có hỏi điểm này, và tôi thấy v1.2 chưa xử lý: §10 vẫn viết cứng “Grace: 7 ngày”. Trong khi hệ thống đã có precedent dot_config.grace_period_days từ Đ35.

Đề xuất fix:

• Reuse dot_config.grace_period_days nếu muốn đồng bộ toàn hệ
• Hoặc seed key riêng context_pack_grace_period_days

Nếu giữ 7 ngày là policy cố định của luật thì phải nói rõ đó là quy định luật, không phải config. Hiện wording hơi lửng giữa policy và runtime config.

5) Cron schedule 0 */3 * * * và 30 */3 * * * — MINOR / CHẤP NHẬN ĐƯỢC nếu xem là seed

Tôi không coi đây là blocker, vì cron của DOT đã có cron_schedule trong metadata và có thể đổi qua đăng ký/patch DOT mà không cần sửa code script. Tuy nhiên, nếu muốn triệt để NT4, nên đổi wording thành:

• đây là seed mặc định, không phải ràng buộc bất biến của Đ43.

6) VOLATILE HEADER markers — CHẤP NHẬN ĐƯỢC

Tôi đồng ý với Desktop: đây là protocol marker nội bộ để tính logical_checksum, không phải khai báo business metadata dư thừa. Không xem là vi phạm NT11.

7) Advisory lock namespace (43,1) — CHẤP NHẬN ĐƯỢC

Đây là protocol ID/namespace ổn định, không phải hardcode business rule cần config hóa.

8) SHA256 làm checksum algorithm — CHẤP NHẬN ĐƯỢC

Tôi không xem đây là vi phạm NT4/NT11. Đây là lựa chọn thuật toán chuẩn cấp giao thức, không cần config hóa ở giai đoạn này.

9) pg_cron vs bash crontab — CHƯA CẦN amend luật v1.2

Tôi nghiêng về không cần sửa v1.2 chỉ để chốt chuyện này. Đây là quyết định triển khai Phase 6, miễn luật giữ mức transport-neutral đủ dùng. Chỉ cần tránh wording quá cứng “crontab duy nhất”.

10) Mustache-style placeholders chưa có SSOT riêng — MINOR

Hiện draft chỉ nhắc template_kb_path + placeholder style, nhưng chưa có nơi chuẩn hóa template contract. Không phải blocker của v1.2, nhưng nên ghi vào phụ lục/OR hoặc template spec riêng để tránh drift renderer sau này.

Khuyến nghị trước ban hành (nếu APPROVE WITH CHANGES)

Blocker cần sửa trước ban hành

1. Bỏ hardcode section_count = 8 ở context_pack_manifest.
2. Làm rõ hoặc sửa lại kiến trúc context_pack_health_checks để Test 5 không còn FAIL. Có 2 phương án hợp lệ:
   • Phương án A: chấp nhận check_type extension là boundary logic-code, sửa prompt/rubric/Q2 wording cho đúng bản chất (Test 5 = PARTIAL, không phải PASS mục tiêu).
   • Phương án B: nâng thiết kế lên generic SQL/function executor để thêm H10 thật sự không cần sửa code.
3. Bổ sung field chỉ định nguồn dữ liệu/render cho context_pack_section_definitions (source_ref / query_kb_path / render_config) để section mới thêm bằng INSERT row có thể render thật.

Minor nên vá luôn nếu tiện

4. Config hóa grace period hoặc explicit reuse dot_config.grace_period_days của Đ35.
5. Đổi wording cron schedule thành seed mặc định, không phải giá trị bất biến của luật.

Kết luận

v1.2 là amend đúng hướng và rõ ràng tốt hơn v1.1 về mặt tuân HP: Desktop đã bắt đúng bệnh “hardcode làm hệ thống mở rộng phải sửa code”. Tuy nhiên bản draft hiện tại mới giải quyết được phần folder / DB / watched patterns / section metadata cơ bản, còn 2 điểm mở rộng quan trọng nhất vẫn chưa data-driven thật: thêm section mới và thêm loại health check mới. Vì vậy, tôi chấm 6.9/10 — APPROVE WITH CHANGES. Chỉ cần vá 3 điểm cứng nêu trên thì v1.2 sẽ hợp lý để ban hành mà không cần redesign triết lý v1.1.