Incomex AI Portal
KB-6454

Council Review — Gói DOT Repair Governance — Round 2 — GPT

24 min read Revision 1
council-reviewgptround2s178-fix15dot-repair-governancedieu22dieu32dieu33dieu35dieu36dieu38dieu39dieu41dieu43

Council Review — Gói DOT Repair Governance — Round 2 — GPT

Ngày: 2026-04-18 | Điểm tổng: 8.9/10 | Phán quyết: APPROVE WITH CHANGES

1. Tóm tắt 1 câu

Bản v2 đã đóng trọn 4 blocker của Round 1 và tiến rất gần mức FINAL, nhưng Round 2 rà chéo liên luật và integrity runtime vẫn còn 4 điểm phải khóa thêm: race window M2→M3, coalesce parent/child chưa thấy schema parent_issue_id, ON UPDATE CASCADE trên code tables có nguy cơ làm trôi lịch sử APR, và high-risk Council routing hiện vẫn thiên về text policy hơn là cơ chế enforceable.

2. Đánh giá từng Patch (P1 Đ41 / P2 Đ32 / P3 Đ35 / P4 Đ22)

P1 — Đ41 v1.0 → v1.1: ops-code/ + log schema

Điểm: 9.2/10

Đạt:

  • v2 đã sửa đúng điểm Round 1: ops-code/ được định nghĩa là logical deployment class, không còn bị hiểu là một thư mục cứng.
  • Thêm deploy_kind vào vps_deploy_log là bước rất đúng NT10, biến ops-code từ text policy thành field có constraint.
  • §5.8.1 giữ phân loại Loại B / Loại C cho ops-code nếu đụng data/schema là đúng tinh thần Đ41 và tránh vùng xám “chỉ là script nên khỏi cần governance data”.

Thiếu / cần siết thêm:

  • deploy_kind đã có, nhưng P3 ADMIN fallback lại nói “ghi admin_fallback_reason trong log” trong khi P1 chưa amend schema log cho field này. Nếu đẩy vào notes/smoke_evidence thì phải viết rõ đó là JSONB contract, nếu không lại rơi vào text-before-PG.
  • P1 chưa nói rõ ops-code_registry là bảng thật hay chỉ là tên khái niệm. Trong P1/P4/P9 có nhiều chỗ nhắc tới ops_code_registry, nhưng tôi chưa thấy schema bảng này trong patch v2.

Wording cần sửa:

  • Ghi rõ: “nếu chưa có bảng ops_code_registry, nguồn sự thật hiện tại cho membership của ops-code/ là dot_tools.file_path + deploy_kind='ops-code' trong vps_deploy_log; ops_code_registry chỉ được dùng sau khi ban hành riêng.”
  • Nếu muốn dùng admin_fallback_reason như field chuẩn, phải amend schema vps_deploy_log; nếu không, định nghĩa rõ JSON structure trong smoke_evidence hoặc notes.

Đề xuất cụ thể:

  • P12: hoặc thêm cột admin_fallback_reason, manual_approved_by, retro_apr_code vào vps_deploy_log, hoặc chuẩn hóa smoke_evidence JSONB contract cho admin fallback.

P2 — Đ32 v1.0 → v1.1: PG-native action/request types + schema split

Điểm: 8.8/10

Đạt:

  • P5 đã merge đúng trọng tâm: tách request_type_code và proposed_action_code khỏi proposed_action JSONB. Đây là chỗ v2 sửa rất tốt NT10 + NT11.
  • ON DELETE RESTRICT là quyết định đúng để giữ lịch sử APR.
  • §3.5 sequencing 8 bước đã tốt hơn rõ rệt so với v1.
  • §3.4 bổ sung đăng ký Đ36 cho 2 bảng type là hợp lý.

Thiếu / blocker kỹ thuật:

  • ON UPDATE CASCADE chưa phải lựa chọn tốt cho bảng type mang tính pháp trị/audit. Nếu sau này rename patch_ops_code → ops_code_patch, hệ thống sẽ cascade vào toàn bộ APR cũ. Về referential integrity thì đúng, nhưng về audit semantics thì không đẹp: lịch sử “tại thời điểm đó request dùng action code gì” bị viết lại theo tên mới. Với bảng governance/type tables, tôi nghiêng mạnh về ON UPDATE RESTRICT hơn CASCADE.
  • risk_level routing đã được mô tả, nhưng chưa có bằng chứng schema/flow lưu quorum review hoặc approval evidence cho high-risk action. Hiện nhìn giống policy text hơn là runtime-enforced rule.
  • dot-apr-type-integrity-audit đang ghi là “B-tier” nhưng mô tả hành vi lại là scanner/audit. Theo Đ35 triết lý DOT cặp, công cụ quét phát hiện lệch nên là A-tier, còn repair/propose mới là B-tier hoặc pseudo. Chỗ này đang lệch triết lý nội tại.
  • Tên paired trong patch đang viết “Paired: dot-apr-type-integrity-repair (pseudo — tạo APR suggestion, không auto-fix)”. Nếu là tạo APR suggestion thì về bản chất là động cơ thực thi mức nhẹ, không nên gọi là repair nếu nó không repair.

Wording cần sửa:

  • Đổi ON UPDATE CASCADE → ON UPDATE RESTRICT cho cả 3 FK liên quan đến type codes.
  • Đổi “dot-apr-type-integrity-audit (B-tier)” thành A-tier.
  • Đổi “repair” thành “propose” cho paired DOT nếu nó chỉ sinh APR.

Đề xuất cụ thể:

  • P10: Amend FK policy cho apr_action_types, apr_request_types, approval_requests từ ON UPDATE CASCADE sang ON UPDATE RESTRICT; rename code trở thành hoạt động loại amend đặc biệt, không được tùy tiện.
  • P13: Bổ sung bảng/quy ước approval_request_reviews hoặc equivalent để high-risk action thực sự enforce được “2 AI + Chủ tịch”, thay vì chỉ là text policy.

P3 — Đ35 v5.1 → v5.2: flow fix_repair_dot + verify 3 tầng + admin fallback

Điểm: 9.0/10

Đạt:

  • §6.4.1 verify 3 tầng là patch rất đúng bài học Đ43 rev 2.
  • §6.5 admin fallback xử lý đúng nghịch lý “APR engine hỏng thì không thể dùng APR để sửa APR engine”. Đây là bổ sung tốt.
  • Tách timeline paired-test 30 ngày cho nhóm lõi, 90 ngày cho phần còn lại là hợp lý hơn v1.

Thiếu / cần siết:

  • ADMIN fallback chưa có cấu trúc audit PG riêng hoặc contract PG đủ cứng. Hiện mới có yêu cầu ghi note/log và APR retroactive. Với NT10, chỗ này vẫn thiếu SSOT rõ cho bằng chứng phê duyệt fallback.
  • P3 đang nói “APR retroactive document để audit”, nhưng không nói rõ retroactive APR có field nào chỉ ra nó là hồ sơ hóa sau sự kiện, tránh bị nhầm với APR phê duyệt trước khi sửa.
  • P3 chưa khóa hành vi khi system đang ở giữa M2 backfill: nếu dot-apr-execute runtime mới bật trong khi legacy row chưa backfill xong, flow fix_repair_dot có thể nhìn thấy một phần trạng thái cũ và mới cùng lúc.

Wording cần sửa:

  • Thêm “retroactive APR phải mang evidence_mode='post-fallback-audit' hoặc field tương đương, không được trộn với APR chuẩn pre-approval.”
  • Thêm “trong M2→M3, approval_requests phải ở trạng thái maintenance gate hoặc dual-write compatibility mode.”

Đề xuất cụ thể:

  • P11: thêm maintenance gate / advisory lock / write-freeze cho approval_requests khi backfill M2 đang chạy; hoặc triển khai dual-write tạm thời ở dot-apr-propose để vừa ghi legacy text vừa ghi code fields cho đến khi verification xong.
  • P12 dùng chung với P1: audit schema cho admin fallback.

P4 — Đ22 v1.0 → v1.1: silent-fail enforcement + annotation + coalesce

Điểm: 8.7/10

Đạt:

  • Annotation + risk-tier đã giải quyết đúng blocker regex/false-positive của Round 1.
  • Scanner path từ registry/config là đúng NT4.
  • Tách 14/30/90 ngày theo scope rõ ràng là tốt.

Thiếu / blocker kỹ thuật:

  • Patch v2 nói scanner coalesce issue thành parent + children qua system_issues.parent_issue_id, nhưng tôi chưa thấy bằng chứng schema field này tồn tại trong dữ liệu registry hiện có. table_registry của system_issues đang chỉ lộ code, title, issue_type, severity, source, status, detected_at; không lộ parent_issue_id.
  • Nếu cột này chưa tồn tại, cơ chế coalesce hiện vẫn là text assumption, chưa phải runtime feature.
  • dot-ops-silent-fail-scan là A-tier, dot-ops-silent-fail-propose là pseudo — phần này hợp lý hơn P2; tuy nhiên patch v2 chưa nói rõ cách tránh vòng lặp khi scanner chính phát hiện lỗi trong chính scanner pair của nó.

Wording cần sửa:

  • Thêm clause: “Nếu system_issues.parent_issue_id chưa tồn tại, amend schema phải chạy trước khi bật coalesce.”
  • Thêm rule chống self-loop: scanner không tự APR cho chính issue batch của session hiện tại; chỉ escalate lên parent issue.

Đề xuất cụ thể:

  • P14: ALTER system_issues thêm parent_issue_id BIGINT NULL REFERENCES system_issues(id) ON DELETE SET NULL, coalesce_key TEXT, index (parent_issue_id), index partial cho coalesce_key WHERE status='open'.

3. Tuân thủ 13 NT Hiến pháp

NT1 — SSOT duy nhất

Đạt mạnh hơn v1, nhưng còn 2 điểm cần khóa.

  • P9 định vị ops-code vào 3 lớp HP là đúng và cần thiết.
  • P2 split *_code + payload là đúng NT1.
  • Tuy nhiên ops_code_registry vẫn đang là khái niệm chưa chứng minh có schema thật; và ON UPDATE CASCADE trên action/request code có nguy cơ làm SSOT lịch sử APR bị “đổi tên hồi tố”.

NT2 — Tự động 100%

Đạt hướng, còn một race quan trọng.

  • P4 scanner và P3 flow repair đều tự động khá tốt.
  • Nhưng M2→M3 nếu không có gate sẽ tạo trạng thái “nửa cũ nửa mới”, làm tự động không còn deterministic.

NT3 — DOT 100% (có ngoại lệ)

Không có vi phạm mới rõ ràng.

  • Đ33 §13 cho phép PG-only trong vài ngoại lệ; gói v2 không đi ngược hướng đó.
  • ADMIN fallback là ngoại lệ vận hành hợp lý cho DOT lõi bị chết, nhưng phải có audit PG cứng thì mới không biến thành bypass mơ hồ.

NT4 — Config > hardcode

Đạt rất rõ so với v1.

  • Scanner path, deploy_kind, request/action types đều được config/PG hóa.
  • risk_level routing vẫn còn thiếu phần “enforcement engine”, nên mới chỉ config được policy chứ chưa config được outcome chắc chắn.

NT5 — Tự phát hiện, tự sửa

Đạt tốt.

  • P4 phát hiện, P3 sửa, verify, rollback — vòng này khá đẹp.
  • Điểm còn thiếu là coalesce parent/child chưa chắc đã thực thi được do thiếu schema bằng chứng.

NT6 — 5 tầng đồng bộ / cấm bypass

Không thấy vi phạm trực tiếp.

  • P9 còn giúp ops-code không thành lớp lạ ngoài HP.

NT7 — Dual-trigger

Không có xung đột mới.

  • Gói v2 dùng nhiều cron + event/pair khá ổn.

NT8 — Assembly First

Đạt.

  • P2 dùng PG type tables thay vì bash hardcode.
  • Không có xu hướng tự đẻ engine riêng thay vì tận dụng PG.

NT9 — Không chắc đúng = sai

Đạt rất mạnh.

  • Toàn gói vẫn giữ tinh thần “không cover → dừng” và “fix flow trước khi fix bug”.

NT10 — Quản lý bằng PG, không bằng text

Tiến bộ rõ, nhưng chưa xong 100%.

  • deploy_kind, code tables, split schema là rất đúng NT10.
  • Còn lại 2 lỗ nhỏ: parent_issue_id chưa chứng minh có thật, và high-risk Council approval chưa có cấu trúc review evidence rõ ràng trong PG.

NT11 — Khai tối thiểu, thông tin tối đa

Đạt.

  • Tách code khỏi payload đúng đẹp.
  • Cần giữ nguyên tắc này khi bổ sung admin fallback audit, tránh đẻ bảng thừa nếu có thể dùng JSONB contract trong log hiện có.

NT12 — DOT theo cặp

Đạt nhưng còn một cặp gọi tên lệch vai.

  • P4 cặp scan/propose hợp lý.
  • P2 dot-apr-type-integrity-audit đang gắn B-tier là lệch bản chất.

NT13 — Ưu tiên PG native

Đạt.

  • P2/P9 đi đúng tinh thần PG-first.
  • Không thấy tự đẻ service không cần thiết.

4. Rà chéo luật liên quan

Hiến pháp v4.6.2 / v4.6.3 dự kiến

Đánh giá: tương thích sau khi P9 được enact.

  • P9 sửa đúng lỗ kiến trúc: ops-code không thành “layer thứ 4.5” ngoài HP mà được neo vào Lớp Kho, nhất quán với Đ33 §0.2 và chính HP phần 3 lớp. Điều này giúp P1 không vi phạm NT1/NT6.
  • Không thấy xung đột với 13 NT; ngược lại v2 dùng P9 để đóng xung đột kiến trúc từ v1.

Lưu ý: gói đang viện dẫn HP v4.6.3 nhưng KB hiện tôi đọc vẫn là constitution.md v4.6.2. Đây chưa phải blocker, nhưng Round 2 chỉ nên FINAL sau khi wording nâng version được ghi đồng bộ vào HP/Đ35/mục lục.

Đ33 PostgreSQL v2.0

Đánh giá: tương thích ở mức định hướng, chưa khóa đủ vài chi tiết DDL/governance.

Đúng:

  • 2 bảng mới apr_action_types, apr_request_types rõ ràng thuộc DB directus / Lớp Kho theo Đ33 §0.1-0.2.
  • Owner hợp logic phải là workflow_admin vì đây là managed collections/business warehouse. Điều này phù hợp Đ33.
  • ON DELETE RESTRICT và register qua Collection Protocol đi đúng tinh thần PG-governed entity.

Thiếu / còn hở:

  • Patch v2 nói “tuân Đ33” nhưng không viết cứng owner cho 2 bảng mới là workflow_admin.
  • Với bảng thì search_path không phải vấn đề chính; nhưng nếu gói sẽ thêm function/trigger hỗ trợ APR typing hoặc audit, nên viết luôn pattern Đ33/Đ35: SECURITY DEFINER + SET search_path = public, pg_catalog để tránh lặp bài học Đ35/Đ43.
  • Không thấy xung đột với Đ33 §13 ngoại lệ DOT 100%: gói vẫn cho DOT/PG-native đi đúng channel hợp pháp, không tạo ngoại lệ mới trái luật.

Kết luận Đ33: không có blocker lớn, nhưng nên bổ sung wording owner/search_path pattern cho completeness kỹ thuật.

Đ36 Collection Protocol

Đánh giá: đúng hướng, nhưng căn cứ hiện có trong KB chưa hoàn hảo vì file tôi đọc là Đ36 v5.0 DRAFT, không phải “Đ36 v4.0 enacted” như prompt nêu.

Đúng:

  • apr_action_types, apr_request_types là 2 collection governance mới, nên P2 §3.4 yêu cầu đăng ký collection_registry + meta_catalog là đúng tinh thần Đ36 GP1/GP4/GP7.
  • Có DOT register/audit cho hai bảng mới là phù hợp với self-healing/health-check logic của Đ36.

Thiếu / cần siết:

  • Tên DOT đang lệch tier như đã nêu ở P2.
  • Nếu Đ36 hiện hành thực tế vẫn dùng khung v4.0 17 health checks, patch nên nêu rõ 2 bảng type này phải vào scope của health/orphan/misclass scanner nào, không chỉ “register rồi thôi”.

Kết luận Đ36: không blocker lớn, nhưng cần bổ sung integration point với health scanners. Tôi cũng cần ghi rõ rằng trong KB hiện tại tôi không thấy file “Đ36 v4.0 enacted” riêng để đối chiếu trực tiếp.

Đ38 Văn bản Quy phạm

Đánh giá: đây là vùng chưa thể xác nhận FINAL hoàn toàn, vì KB hiện có dieu38-normative-document-law.md là v3.0 DRAFT, không phải “Đ38 v2.3 enacted” như prompt nêu.

Điểm tốt:

  • Ý tưởng seed amend_law trong apr_action_types là hợp lý, vì gói amend 4 luật cần vocabulary cho normative change.

Điểm chưa khóa:

  • Tôi chưa thấy bằng chứng runtime rõ ràng về dot-nrm-amend đã tồn tại trong các tài liệu vừa đọc. Patch v2 nói amend_law dùng cho flow dot-nrm-amend, nhưng ở trạng thái tài liệu hiện tại, chỗ này vẫn nghiêng về assumption.
  • Vì Đ38 trong KB là draft, việc nói “flow amend 4 luật cùng phiên đã tương thích hoàn toàn” là quá sớm nếu không có artifact runtime kèm theo.

Kết luận Đ38: cần một patch/clarification nhỏ:

  • hoặc đánh dấu amend_law là reserved action code cho flow normative khi dot-nrm-amend được ban hành/kiểm chứng,
  • hoặc viện dẫn artifact/path của runtime đó nếu nó đã tồn tại mà tôi chưa được cung cấp.

Đ39 Knowledge Graph

Đánh giá: không thấy xung đột logic; auto-update binding có cơ sở kiến trúc, nhưng cần verify thay vì khẳng định cứng.

  • Đ39 §5.C1 và §6.E nói khá rõ Scaffold Build được trigger khi Đ38 enacted/update, có partial invalidation. Vì vậy nhận định của patch v2 rằng binding/graph “không cần action thủ công, verify sau enact” là hợp logic.
  • Tuy nhiên do Đ38 hiện đọc được là draft, nên kết luận mạnh nhất tôi có thể đưa là: Đ39 không xung đột, nhưng phụ thuộc vào việc Đ38 runtime trigger/binding thực sự đang live.

Kết luận Đ39: không blocker, nhưng nên đổi wording “Không cần action thủ công” thành “Không cần DOT manual mới nếu trigger/binding pipeline Đ38 đang live; bắt buộc verify sau enact.”

Đ43 Bản đồ Hệ thống v1.2

Đánh giá: không blocker, nhưng patch v2 đang hơi lạc quan khi ghi “làm sau, không block”.

  • Đ43 context pack hiện có PROJECT_MAP, DOT_REGISTRY, DB_MAP, ARCHITECTURE.mmd… nên ops-code ở mức nào đó sẽ hiện gián tiếp qua DOT registry và scan path nếu đã register đúng.
  • Nhưng tôi chưa thấy section riêng hoặc section_definitions entry nào mô tả ops-code layer như một concept rõ ràng. Nếu P9 chính thức đưa ops-code vào HP kiến trúc, Đ43 về sau nên có ít nhất một chỗ render ra nó để AI phiên sau không phải suy luận vòng vo.

Kết luận Đ43: không blocker cho gói amend, nhưng nên mở technical debt hoặc patch nhỏ về context-pack section/model để phản ánh ops-code rõ hơn.

5. Technical integrity deep-dive

5.1 Sequencing M1→M4 và race condition M2→M3

Đây là blocker lớn nhất còn lại.

Patch v2 đã có 8 bước sequencing P2, nhưng vẫn thiếu quy tắc xử lý concurrent APR writes trong cửa sổ:

  • đã tạo bảng type,
  • đã thêm 2 cột code nullable,
  • đang backfill legacy,
  • nhưng runtime mới chưa hoặc vừa mới được bật.

Race cụ thể:

  • Một APR legacy mới được tạo đúng lúc step 4 backfill đang chạy.
  • Row đó có request_type text / payload JSONB nhưng chưa có *_code mapping.
  • Verification step 5 có thể PASS cho snapshot vừa kiểm xong, nhưng ngay sau đó step 6 bật runtime đọc bảng type → row mới lại thành orphan/missing code.

Kết luận: step 4-6 hiện chưa đủ đóng race. Cần một trong 2 mô hình:

Mô hình A — Maintenance gate / advisory lock

  • bật maintenance mode cho approval_requests write path,
  • lock dot-apr-propose / dot-apr-execute,
  • backfill xong + verify xong mới mở lại.

Mô hình B — Dual-write compatibility window

  • từ đầu step 3, dot-apr-propose phải ghi cả text legacy lẫn *_code mới,
  • backfill chỉ xử lý historical rows,
  • verification query phải check cả rows sinh trong cửa sổ migration,
  • sau 14 ngày observation mới bỏ đọc legacy.

Tôi nghiêng về Mô hình B nếu muốn zero-downtime; nếu không, A đơn giản và an toàn hơn.

5.2 ON UPDATE CASCADE trên type codes

Không nên giữ.

  • Với bảng transactional/business thường, CASCADE khi rename code có thể chấp nhận được.
  • Với approval history và vocabulary governance, rename code rồi cascade qua APR cũ sẽ làm lịch sử ngôn ngữ bị viết lại. Audit trail kém tin cậy hơn.
  • Tôi khuyến nghị ON UPDATE RESTRICT; nếu thật sự cần đổi code, phải tạo migration/audit riêng và chấp nhận đó là thay đổi quy phạm, không phải thao tác thường.

5.3 CHECK status enum ('active','deprecated','retired')

Đủ cho type tables.

  • Không cần thêm pending/review ở đây, vì đó là lifecycle của approval_requests, không phải lifecycle của action/request type definitions.
  • active/deprecated/retired là phù hợp cho vocabulary tables.

5.4 Parent/children system_issues coalesce

Thiếu schema bằng chứng.

  • Patch v2 phụ thuộc vào system_issues.parent_issue_id, nhưng tôi không thấy field này trong registry tôi đọc.
  • Nếu field chưa tồn tại, coalesce hiện không thể là runtime truth.
  • Ngoài parent_issue_id, nên có coalesce_key hoặc equivalent để batch dedupe/coalesce deterministic hơn.

5.5 ADMIN fallback §6.5

Ý tưởng đúng, audit chưa đủ cứng.

  • Manual backup/patch/log + retroactive APR là hợp logic cho emergency.
  • Nhưng với NT10, câu hỏi là: log ở đâu, field nào, ai approve, vì sao fallback, retro APR nào nối lại?
  • Hiện patch v2 chưa đủ chi tiết schema để máy query/verify được, trừ khi các dữ liệu này được chuẩn hóa trong vps_deploy_log.smoke_evidence/notes JSONB.

Khuyến nghị: không bắt buộc phải tạo admin_fallback_log riêng nếu tái sử dụng vps_deploy_log đủ tốt; nhưng phải chuẩn hóa field contract để tránh text tự do.

5.6 Risk-level routing §3.3

Chưa thấy runtime engine enforceable.

  • “high → Council (2 AI + Chủ tịch)” hiện mới là governance policy hợp lý.
  • Nhưng tôi chưa thấy schema/flow cho quorum review: ai là AI-1, AI-2, Chủ tịch, trạng thái mỗi review, rule PASS là gì, DOT nào chặn apply nếu chưa đủ quorum.
  • Nếu không có cấu trúc này, dot-apr-execute vẫn có nguy cơ chỉ nhìn approved đơn trị rồi apply.

Kết luận: đây không phải lỗi triết lý, mà là thiếu implementation contract. Round 2 chưa nên FINAL nếu phần này chưa được khóa.

6. Bỏ sót / rủi ro

  1. Đ38 runtime assumption còn mơ hồ: amend_law đã seed nhưng dot-nrm-amend chưa được chứng minh là thực thể live trong tài liệu tôi đọc.
  2. ops_code_registry chưa có bằng chứng schema: patch nhiều chỗ viện dẫn nhưng chưa thấy định nghĩa thật.
  3. Tier naming lệch ở P2 DOT mới: audit tool bị ghi B-tier.
  4. Context Pack / Đ43 chưa phản ánh ops-code như concept rõ: không block, nhưng sẽ làm AI phiên sau vẫn phải suy luận vòng vo.

7. Patch đề xuất bổ sung (P10, P11, …) — nếu có

P10 — FK immutability cho APR type tables

Mục tiêu: bảo toàn audit semantics.

Nội dung:

  • đổi toàn bộ ON UPDATE CASCADE liên quan apr_action_types, apr_request_types, approval_requests.*_code thành ON UPDATE RESTRICT.
  • nếu cần đổi code, phải đi migration/amend riêng có audit.

P11 — Migration gate cho M2→M3

Mục tiêu: đóng race window khi backfill APR legacy.

Nội dung:

  • chọn 1 trong 2:
    • maintenance gate + advisory lock, hoặc
    • dual-write compatibility trong dot-apr-propose.
  • verification query sau step 5 phải chạy trên quiesced state hoặc đảm bảo mọi row phát sinh trong cửa sổ đều đã có *_code.

P12 — Structured audit cho ADMIN fallback

Mục tiêu: làm fallback khẩn cấp vẫn query/verify được theo NT10.

Nội dung:

  • hoặc amend vps_deploy_log thêm fields:
    • admin_fallback_reason TEXT
    • manual_approved_by TEXT
    • retro_apr_code TEXT
  • hoặc chuẩn hóa 3 field này trong smoke_evidence JSONB với contract cố định và document hóa rõ.

P13 — Enforceable quorum cho high-risk approval

Mục tiêu: biến “2 AI + Chủ tịch” từ text policy thành runtime rule.

Nội dung:

  • tạo bảng approval_request_reviews hoặc equivalent:
    • approval_request_id
    • reviewer_type (ai/chairman)
    • reviewer_id
    • decision
    • reviewed_at
  • dot-apr-execute với high-risk chỉ APPLY khi đủ quorum rule.

P14 — Schema cho system_issues coalesce parent/child

Mục tiêu: làm P4 coalesce thành thực thể thật.

Nội dung:

ALTER TABLE system_issues
  ADD COLUMN parent_issue_id BIGINT NULL REFERENCES system_issues(id) ON DELETE SET NULL,
  ADD COLUMN coalesce_key TEXT NULL;

CREATE INDEX idx_system_issues_parent_issue_id ON system_issues(parent_issue_id);
CREATE INDEX idx_system_issues_coalesce_open ON system_issues(coalesce_key) WHERE status='open';

P15 — Clarify reserved/active status của amend_law

Mục tiêu: tránh hiểu nhầm P2 đang mở action runtime khi Đ38 flow amend chưa được chứng minh live.

Nội dung:

  • thêm trạng thái reserved cho action code, hoặc giữ active nhưng ghi rõ handler_ref chỉ được enable sau khi dot-nrm-amend được register/verify.
  • nếu không muốn thêm state mới, ít nhất thêm clause “runtime enable flag” trong handler.

8. Quyết định cuối + lý do

Phán quyết cuối: APPROVE WITH CHANGES

Lý do:

  1. v2 đã giải quyết đúng 4 blocker Round 1 và nâng chất lượng gói lên rõ rệt; đây là tiến bộ thực sự, không phải vá wording bề mặt.
  2. Không còn blocker triết lý lớn giữa Đ41/Đ32/Đ35/Đ22 như v1.
  3. Nhưng Round 2 technical integrity vẫn còn 4 hở chính:
    • (A) M2→M3 race window chưa khóa.
    • (B) system_issues.parent_issue_id chưa được chứng minh là schema thật.
    • (C) ON UPDATE CASCADE nên đổi thành RESTRICT để bảo toàn history.
    • (D) high-risk Council routing chưa có execution contract đủ cứng.

Điều kiện để lên APPROVE FINAL:

  • Tối thiểu phải apply P10 + P11 + P14.
  • P12 và P13 có thể là “final-inline” hoặc “pre-enact same PR”, nhưng tôi nghiêng về nên có luôn để tránh admin fallback và high-risk approval vẫn là text policy.

Ghi chú về bằng chứng và giới hạn đối chiếu vòng này

Tôi đã đối chiếu trực tiếp patch v2 với constitution.md, dieu33-postgresql-law.md, dieu36-collection-protocol-law.md, dieu38-normative-document-law.md, dieu39-knowledge-graph-law.md, dieu43-system-context-law.md, cùng một số registry/report liên quan.

Tuy nhiên có 2 giới hạn cần nói rõ:

  1. Trong KB hiện tôi không thấy file “Đ36 v4.0 enacted” riêng, chỉ thấy dieu36-collection-protocol-law.md là v5.0 DRAFT có ghi chú v4.0 từng enacted.
  2. Trong KB hiện tôi không thấy Đ38 v2.3 enacted, mà thấy dieu38-normative-document-law.md là v3.0 DRAFT. Vì vậy phần xác nhận xung đột với runtime amend của Đ38 chỉ có thể kết luận ở mức thận trọng, không thể khẳng định tuyệt đối FINAL.