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

Agent: Incomex Hội đồng AI / GPT Score: 8.9/10 Verdict: APPROVE WITH MINOR

Tóm 1 câu

14 patch chính của Round 1 đã được áp đúng hướng và đã đóng gần hết blocker R1; bản v1.1 còn 3 lỗi triển khai mức minor/integrity cần vá inline rồi có thể ban hành, không cần Round 3.

C1 — Patches apply đúng?

Patch	Status	Nhận định
P1 — downgrade NT14 khỏi HP → clause §3.1 A/B/C	OK	Apply đúng tinh thần R1. Không còn ép amend HP ngay. Đóng blocker “NT chưa enforce được nhưng đẩy lên HP”.
P2 — `context_trigger_sources` lookup table	OK	Apply chuẩn. FK rõ, semantic tách khỏi `dot_trigger_types` của Đ35. Đóng blocker enum/check inline mơ hồ.
P3 — `context_pack_requests` queue + `dedupe_bucket`	OK (partial)	Đã thêm queue chống storm và đi đúng hướng. Tuy nhiên wording runtime ở §6 dùng các giá trị `skipped_coalesced` / `skipped_unchanged` không khớp enum `status` ở §5.2. Cần vá inline.
P4 — manifest bỏ UNIQUE(checksum), thêm publish fields	OK	Apply đúng. Đóng blocker semantics “mỗi build 1 row”.
P5 — `section_name` CHECK enum	OK	Apply đúng. Đóng blocker typo/section drift.
P6 — `pg_try_advisory_lock(43,1)`	OK	Apply đúng và tốt hơn bản cũ. Không còn lock cứng `43001`.
P7 — checksum compare skip nếu không đổi	OK (partial)	Có apply, nhưng hiện draft chưa tách rõ checksum logic content với checksum file có header volatile. Nếu checksum tính trên file cuối có `generated_at`/`Manifest ID`, cơ chế skip sẽ gần như luôn miss. Patch có ghi, nhưng chưa đóng hoàn toàn mục tiêu chống bloat.
P8 — Bước 7 rewrite 2-phase publish + compensation	OK (partial)	Rewrite đúng hướng và đã đóng blocker “atomic giả”. Tuy nhiên còn 1 race cuối: nếu 7c FS live xong mà 7e UPDATE manifest fail thì DB vẫn `staging` trong khi FS đã live. Cần thêm repair clause / retry marker inline.
P9 — chốt `birth_registry`, bỏ `pivot_count()`	OK	Apply đúng. Đóng blocker xung đột Đ0-G / Đ26.
P10 — `git_commit` fallback chain	OK	Apply đúng, thực dụng hơn bản cũ.
P11 — `trigger_type='cron'`, `coverage_status='complete'`, secondary trong `extra_metadata`	OK	Apply đúng precedent Đ35. Đóng blocker enum DOT.
P12 — `fn_log_issue()` đúng 5 params	OK	Apply đúng pattern Đ35 v5.1.
P13 — H5 2 ngưỡng 15KB WARN / 20KB CRITICAL	OK	Apply đúng, đóng mâu thuẫn nội bộ size threshold.
P14 — on-deploy chỉ fire sau Đ41 Bước 6.5 `is_known_good=true`	OK	Apply đúng và đóng race chính với Đ41 deploy critical path.

Kết luận C1: 14 patch đã được apply đúng hướng. Có 3 patch trạng thái OK (partial) do còn thiếu 1 lớp wording triển khai cuối, nhưng không còn blocker kiểu Round 1.

C2 — Bug mới?

1) Enum `context_pack_requests.status` đang lệch với wording runtime

Đây là lỗi rõ nhất mới phát sinh sau khi thêm queue.

§5.2 định nghĩa status IN ('pending','running','done','skipped','failed')
Nhưng §6 Bước 2 ghi INSERT request skipped_coalesced
Và §6 Bước 6 ghi INSERT request skipped_unchanged

Hai giá trị này không thuộc enum hiện tại, nên nếu implement đúng như luật sẽ fail hoặc dev phải tự suy diễn.

Patch inline: giữ status='skipped', chuyển reason vào detail.reason:

status='skipped', detail='{"reason":"coalesced"}'
status='skipped', detail='{"reason":"unchanged"}'

2) Checksum-skip hiện có nguy cơ luôn miss vì file header volatile

§6 Bước 5 yêu cầu render file với git_commit + generated_at header; PROJECT_MAP.md còn có Manifest ID và Checksum. Nếu checksum ở Bước 6 tính trên toàn file render cuối, mỗi build sẽ khác vì timestamp/manifest thay đổi, dù nội dung logic không đổi.

Hệ quả:

skipped_unchanged trên thực tế gần như không bao giờ xảy ra
mục tiêu giảm KB bloat chưa đạt
verify sẽ vẫn thấy run mới liên tục dù không có drift thật

Patch inline: định nghĩa 2 lớp checksum:

logical_checksum_sha256 — tính trên body chuẩn hóa, bỏ header volatile (generated_at, manifest_id, self-checksum)
file_checksum_sha256 — tính trên file cuối để verify drift/tamper

Bước 6 compare theo logical_checksum_sha256; H3 verify theo file_checksum_sha256.

3) Bước 7 còn 1 trạng thái kẹt nếu 7c thành công nhưng 7e fail

Bản v1.1 đã honest hơn rất nhiều, nhưng vẫn còn lỗ hổng cuối:

7c symlink swap thành công → FS live mới đã chạy
7d promote KB live xong hoặc chưa xong
7e UPDATE manifest publish_status='live' fail

Khi đó v_context_pack_latest vẫn nhìn row cũ hoặc không thấy row mới vì filter publish_status='live', trong khi FS thực tế đã live.

Đây không phải blocker thiết kế, nhưng cần một clause repair rõ để tránh trạng thái “FS live / DB staging”.

Patch inline: thêm 7g:

7g. Nếu 7c đã thành công nhưng 7e fail:
- giữ manifest `publish_status='failed'`
- ghi `detail.publish_step='post_fs_pre_db_finalize'`
- `dot-context-pack-verify` hoặc `dot-context-pack-build --repair-publish` phải phát hiện symlink current trỏ build_id mới nhưng manifest chưa live, rồi finalize row hoặc mark failed dứt điểm.

Ngoài 3 điểm trên, tôi không thấy bug mới cấp blocker từ 14 patch.

C3 — Xung đột mới?

1) `context_trigger_sources` vs `dot_trigger_types`

Không phát hiện xung đột. Hai bảng khác semantic:

dot_trigger_types = metadata governance của DOT trong Đ35
context_trigger_sources = nguồn sự kiện runtime để build context pack

Naming đủ rõ, không đụng nhau.

2) `context_pack_requests` có đụng pattern queue sẵn có?

Không thấy xung đột cứng. Nó gần approval_requests ở chỗ là work queue có trạng thái, nhưng scope riêng, không chồng vai trò. Với system_issues, nó cũng khác vì requests là “điều cần làm”, issues là “điều có vấn đề”.

3) on-law-enact trigger trên `kb_documents`

Không phát hiện xung đột mới với HP hay KB Protection, vì Đ43 đã ghi rõ trigger chỉ NOTIFY, không build synchronous, nên không phá trigger stack bảo vệ KB.

Tuy nhiên có 1 wording cần sửa inline:

Draft đang viết WHERE path LIKE 'knowledge/dev/laws/%'
Nhưng KB schema đã ghi nhận trước đó dùng key TEXT PK + data JSONB

Vì vậy clause trigger nên viết theo field thực tế của KB store, ví dụ NEW.key LIKE 'knowledge/dev/laws/%', hoặc wording trung tính hơn: “path/key logic của KB document”. Đây là lỗi mapping field, không phải xung đột luật.

4) Mức B attestation có cần clause trong Đ38 không?

Không cần bắt buộc ở đợt này. Mức B là quy tắc vận hành AI/tool wrapper, chưa phải cấu trúc văn bản quy phạm hay render normative document. Đ38 chỉ cần động tới nếu sau này muốn SQL-hoá “attestation records” như một loại văn bản/quy trình riêng.

C4 — Verdict

Score: 8.9/10
Verdict: APPROVE WITH MINOR

Lý do

Bản v1.1 đã đóng được hầu hết blocker Round 1:

enum DOT đã khớp Đ35,
NT14 đã được hạ khỏi HP,
atomicity giả đã được thay bằng 2-phase publish honest,
queue chống storm đã có,
đường đếm với Đ0-G/Đ26 đã chốt,
on-deploy đã né đúng critical path của Đ41.

Phần còn lại là 3 lỗi triển khai nhỏ nhưng thực:

enum status vs skipped_coalesced/skipped_unchanged,
checksum-skip chưa tách checksum logic khỏi header volatile,
thiếu repair clause khi FS live nhưng finalize DB fail.

Ba điểm này vá inline là xong, không cần Round 3.

Patches inline đề xuất

Inline Patch A — Chuẩn hóa `context_pack_requests.status`

Sửa mọi wording ở §6:

skipped_coalesced → status='skipped', detail.reason='coalesced'
skipped_unchanged → status='skipped', detail.reason='unchanged'

Inline Patch B — Tách checksum logic / checksum file

Bổ sung vào §5.4 hoặc §6:

Mỗi section có 2 checksum:
- `logical_checksum_sha256`: tính trên body chuẩn hóa, bỏ header volatile
- `file_checksum_sha256`: tính trên file render cuối cùng
Bước 6 compare theo `logical_checksum_sha256`.
H3 verify drift/tamper theo `file_checksum_sha256`.

Inline Patch C — Clause repair cho trạng thái `FS live / DB staging`

Bổ sung vào §6 Bước 7:

Nếu 7c thành công nhưng 7e fail, manifest phải UPDATE/mark `failed` với `detail.publish_step='post_fs_pre_db_finalize'`.
DOT verify hoặc build --repair-publish phải phát hiện và finalize/repair trong vòng chạy kế tiếp.

Inline Patch D — Sửa field trigger `kb_documents`

Thay wording:

AFTER INSERT OR UPDATE ON kb_documents WHERE document key/path logic LIKE 'knowledge/dev/laws/%'

hoặc viết cứng theo schema thật đang dùng (NEW.key LIKE ...) nếu Desktop xác nhận field chính thức là key.

Khuyến nghị ban hành

Ban hành sau khi apply 4 patch inline trên cùng PR là đủ. Không cần Round 3.