KB-AA5C

Codex Audit Đ43 — Code Review 7 góc

11 min read Revision 1
dieu43auditcodexcode-reviewread-only2026-04-18

CODEX AUDIT — ĐIỀU 43 CODE REVIEW

Files đã đọc

  • build.sh/opt/incomex/dot/bin/dot-context-pack-build.sh — spec Đ43 v1.2 rev 6 — 1407 dòng
  • verify.sh/opt/incomex/dot/bin/dot-context-pack-verify.sh — spec Đ43 v1.2 rev 6 — 830 dòng
  • cp-render-section.py/opt/incomex/dot/lib/cp-render-section.py — renderer generic rev 6 — 282 dòng

Luật đã đối chiếu

  • Hiến pháp Kiến trúc v4.6.2
  • Điều 43 v1.2 FINAL rev 6
  • Điều 33 PostgreSQL v2.0
  • Operating Rules SSOT v7.57-draft
  • .claude/skills/incomex-rules.md

Tổng kết 1 câu

Có vấn đề nghiêm trọng: khung generic đã đi đúng hướng, nhưng production hiện còn 2 lỗi chặn luật/production và 1 lỗ hổng repair khiến hệ này chưa đạt mức “muốn làm nhầm cũng không thể”.

Phát hiện theo 7 góc

Góc 1 — Hardcode

  • DB fn_context_pack_on_law_enact line 9 đọc _cp_patterns_cache thay vì đọc dot_config.context_pack_watched_key_patterns runtime. Đây là hardcode gián tiếp qua cache snapshot, trái Đ43 rev 2/rev 6 §11 Bước 12§6.X P11. Hậu quả: đổi pattern trong dot_config không chắc có hiệu lực ngay event kế tiếp.
  • knowledge/current-state/queries/laws_index.sql line 1-15 cũng đọc _cp_patterns_cache và còn hardcode mapping laws/ssot/architecture bằng CASE. Điều này làm laws_index phụ thuộc cache thay vì SSOT runtime.
  • dot-context-pack-build.sh:578-580 hardcode find -maxdepth 3. Nếu scan root có file sâu hơn 3 level thì phải sửa code.
  • dot-context-pack-build.sh:1087 hardcode log ${ok}/8 sections live. Logic chính vẫn generic nhưng log vận hành không còn SSOT khi thêm section thứ 9.
  • Điểm tốt: không thấy case-dispatch theo section code trong 3 file mục tiêu; build gọi 1 renderer generic và verify dispatch theo executor_type, phù hợp tinh thần §5.7§9.

Góc 2 — Bảo mật

  • Nghiêm trọng nhất ở production: PG_USER_RO trong .env.production đúng là context_pack_readonly, nhưng DB incomex_metadata hiện có grants_count = 0default_acl_rows = 0 cho role này, trong khi context_pack_section_definitions khai báo laws_index -> data_source=kb_query -> target_db=incomex_metadata, và query laws_index.sql thực sự đọc kb_documents. Kết quả là:
    • hoặc laws_index sẽ fail khi chạy đúng guard 3,
    • hoặc người vận hành sẽ phải đổi sang role mạnh hơn để chạy được, tức vi phạm guard 3.
  • cp-render-section.py:88-95 dùng RW credentials để đọc dot_config.context_pack_render_config_whitelist. Đây không vi phạm trực tiếp guard 3 của SQL executor, nhưng là gap least-privilege vì helper chỉ đọc mà vẫn cầm secret ghi.
  • Điểm tốt: cả renderer và verify đều có đủ khung 5 guard (path whitelist, token scan, RO role, READ ONLY TX qua PGOPTIONS, timeout).

Góc 3 — Tự động scale (NT2)

  • cp-render-section.py:206-208 trả EX_SKIP cho filesystem_scancustom dù schema context_pack_section_definitions.data_source cho phép hai loại này. Sau đó dot-context-pack-build.sh:704-708 ghi SKIP, nhưng dot-context-pack-build.sh:809-813 sẽ fail vì file output không tồn tại. Nghĩa là thêm section kiểu filesystem_scan hoặc custom vẫn phải sửa code.
  • Code hiện phụ thuộc thêm 3 dot_config key không nằm trong seed 7 key của Đ43 §5.9:
    • context_pack_python_deps (build.sh:295-299)
    • context_pack_render_config_whitelist (cp-render-section.py:94-101)
    • context_pack_dot_register_watch_tiers (DB fn_context_pack_on_dot_register line 9) Bootstrap “đúng theo luật” nhưng không seed thêm 3 key này sẽ fail hoặc không đầy đủ.
  • Điểm tốt: với nhóm pg_query / kb_query / static, thêm section mới đã đi đúng hướng generic: row ở section_definitions + template/query KB + target_db, không cần case-dispatch per-section.

Góc 4 — Fail-safe / Resilience

  • Lỗ hổng repair lớn: dot-context-pack-build.sh:107-116 chỉ gọi release_failure() khi MANIFEST_ID chưa được set. Nhưng dot-context-pack-build.sh:1340-1342 lại xem trạng thái running + manifest_id set là “ambiguous state” và fail. Nếu process crash sau 7f nhưng trước 8, request có thể bị treo ở running mà repair không chốt được.
  • dot-context-pack-build.sh:1263-1268 có lỗi off-by-one: code so new_retry < max_retries. Với config hiện tại max_retries=3, build chỉ schedule retry #1 và #2; đến lần fail thứ 3 thì fail hẳn, tức thực tế chỉ có 2 retry thay vì 3.
  • cp-render-section.py:214-216 xử lý đúng trường hợp template rỗng bằng fail-fast.
  • cp-render-section.py:167-170 xử lý đúng trường hợp SQL 0 row bằng WARN + {} thay vì crash cứng.
  • Build có precheck KB API (build.sh:451-460) nên KB down được bắt sớm ở động cơ chính; verify thì không có precheck tương đương.

Góc 5 — Đúng luật Đ43

  • DB fn_context_pack_on_law_enact line 9-14 không tuân clause rev 2/rev 6 yêu cầu đọc dot_config runtime trong function body; hiện tại đọc _cp_patterns_cache.
  • dot-context-pack-build.sh:833-855dot-context-pack-verify.sh:442-451,514-515 chỉ kiểm tra delimiter / _volatile_header existence, chưa kiểm tra đủ 4 field bắt buộc (generated_at, build_id, git_commit, trigger_source) theo rev 5. Tức format header “sai nhưng có delimiter/key” vẫn có thể PASS.
  • dot-context-pack-verify.sh:479-481 cho H7 return WARN khi thiếu mmdc, và dot-context-pack-verify.sh:749-753 luôn hạ rc=2 xuống WARN bất kể severity trong DB là critical. Điều này làm critical health check bị giảm mức nặng chỉ vì thiếu binary.
  • Điểm tốt:
    • 2 checksum (logical + file) đã được tính và ghi manifest.
    • 2-phase publish hiện thực đúng trật tự lớn: tmp -> staging -> live symlink -> KB -> DB.
    • Cặp DOT build/verify đã tồn tại và cron đã cài cả 2.

Góc 6 — HP tuân thủ

  • NT1/NT4: vi phạm ở chỗ trigger và query luật dựa vào _cp_patterns_cache thay vì SSOT runtime (dot_config).
  • NT2: vi phạm ở chỗ thiếu grant cross-DB cho laws_index, unsupported filesystem_scan/custom, retry off-by-one, và bootstrap key chưa khớp luật.
  • NT5: repair chưa khép kín ở cửa sổ 7f -> 8; H7 critical còn có thể bị degrade thành WARN.
  • NT8: target_db đã được khai đúng trong metadata, nhưng production grant không theo kịp multi-DB assembly, nên đường chạy thực vẫn hỏng.
  • NT12: đạt ở mức cấu trúc vì build/verify là cặp và cron đã cài đủ 2 trigger thời gian.

Góc 7 — Production readiness

  • Cron user incomex đã có đủ 2 job 3 giờ/lần và được comment rõ là auto-generated từ dot_tools.
  • Advisory lock pg_try_advisory_lock(43,1) giúp chống chạy song song; rủi ro race giữa 2 cron là thấp.
  • Daily log naming có (/tmp/dcp-cron-YYYYMMDD.log) nhưng chưa thấy retention/cleanup/compression; đây mới là “daily file naming”, chưa phải log rotation hoàn chỉnh.
  • Build/verify đều fail-fast nếu .env.production thiếu key bắt buộc. Tuy nhiên exact mode/owner của .env.production không được xác nhận trực tiếp trong audit này vì command scope chỉ dùng cat/grep/psql SELECT/crontab -l.

Bảng tổng hợp

# Vấn đề File:Line Severity NT vi phạm Fix đề xuất (KHÔNG làm)
1 Trigger on_law_enact đọc _cp_patterns_cache, không đọc dot_config runtime DB fn_context_pack_on_law_enact:9-14 critical NT1, NT2, NT4 Sửa function đúng rev 2/rev 6: đọc dot_config.context_pack_watched_key_patterns runtime trong function body, bỏ phụ thuộc cache snapshot cho decision path
2 context_pack_readonly không có grant/default ACL ở incomex_metadatalaws_index target DB này và env dùng đúng RO role DB snapshot: context_pack_section_definitions(laws_index), information_schema.role_table_grants, pg_default_acl critical NT2, NT4, NT8 Apply đúng §11.6.4: GRANT SELECT ON ALL TABLES + ALTER DEFAULT PRIVILEGES cho incomex_metadata (và các DB future)
3 Repair không xử lý được crash sau 7f trước 8 (running + manifest_id set) dot-context-pack-build.sh:107-116,1340-1342 high NT5 Mở rộng repair_publish để finalize hoặc close request khi manifest đã được insert nhưng request chưa done
4 Retry logic off-by-one, config max_retries=3 nhưng thực tế chỉ có 2 retry dot-context-pack-build.sh:1263-1268 medium NT2 So sánh trên current_retry < max_retries trước khi increment, hoặc đổi semantics cho rõ ràng trong code + law
5 Validate/verify header chưa enforce đủ 4 field bắt buộc của volatile header rev 5 dot-context-pack-build.sh:833-855; dot-context-pack-verify.sh:442-451,514-515 medium NT9 Check đủ 4 key/field và fail nếu thiếu bất kỳ trường nào
6 filesystem_scan / custom được schema cho phép nhưng renderer chỉ SKIP, thêm section loại này vẫn phải sửa code cp-render-section.py:206-208; dot-context-pack-build.sh:704-708,809-813 medium NT2, NT4 Hoặc implement generic handler cho 2 data_source này, hoặc rút enum ở schema/law để khớp năng lực thực tế
7 Code phụ thuộc thêm 3 dot_config key chưa được seed trong Đ43 §5.9 dot-context-pack-build.sh:295-299; cp-render-section.py:94-101; DB fn_context_pack_on_dot_register:9 medium NT1, NT2 Bổ sung seed/luật cho 3 key hoặc refactor bỏ phụ thuộc nếu không phải SSOT chính thức
8 KB mirror có thể lệch byte thật mà H4 không phát hiện: upload qua shell var strip trailing newline, diff % làm tròn xuống dot-context-pack-build.sh:1048; dot-context-pack-verify.sh:373-396 medium NT5 Upload body bằng file/stream không qua command substitution; H4 tính phần trăm bằng số thực hoặc so byte drift trực tiếp
9 H7 severity critical nhưng thiếu mmdc chỉ ra WARN; build validate cũng silently skip parse nếu thiếu binary dot-context-pack-verify.sh:479-481,749-753; dot-context-pack-build.sh:795-847 medium NT5, NT9 Nếu H7 là critical thì thiếu mmdc phải fail-fast hoặc downgrade severity ngay trong metadata/law cho nhất quán
10 Còn hardcode/hygiene nhỏ: find -maxdepth 3, log ${ok}/8 sections, log file daily chưa có retention dot-context-pack-build.sh:578-580,1087; crontab -l -u incomex low NT4 Config hóa độ sâu scan và section count trong log; bổ sung retention/cleanup cho /tmp/dcp-cron-*

Kết luận

  • Tổng vấn đề: 10 (2 critical, 1 high, 6 medium, 1 low)
  • Sẵn sàng production: CHƯA
  • Hai blocker phải xử trước khi coi là compliant production:
    • fn_context_pack_on_law_enact phải đọc dot_config runtime đúng luật rev 2/rev 6
    • context_pack_readonly phải có grant/default ACL đúng ở incomex_metadata cho laws_index và các query cross-DB
  • Nhận định cuối: kiến trúc generic dispatcher và paired DOT đã đúng hướng, nhưng phần runtime safety và production grant vẫn chưa đạt chuẩn HP/Đ43 hiện hành.