Incomex AI Portal
KB-3C57

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

24 min read Revision 1
council-reviewdieu43gptround1approve-with-changes

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

Agent: Incomex Hội đồng AI / GPT Ngày: 2026-04-16 Score: 7.8/10 Verdict: APPROVE WITH CHANGES

Tóm 1 câu

Đ43 giải đúng bệnh thật và kiến trúc tổng thể hợp lý, nhưng bản v1.0 draft còn 6 blocker triển khai thực tế: enum/trigger chưa khớp Đ35, atomicity bước 7 chưa khép kín, dual-trigger dễ storm, NT12 chưa enforce được nên chưa nên đẩy lên Hiến pháp, và có 2 mâu thuẫn nội bộ size/trigger semantics cần sửa trước khi ban hành.

C1 — Xung đột luật khác

1) Với Hiến pháp v4.5.1

  • Không xung đột mục tiêu, vì Đ43 bám đúng NT1/2/3/5/7/8/9/10/11: context pack được đặt là view/output, không phải SSOT; manifest nằm trong PG; file MD/JSON chỉ là render.
  • Có điểm cần sửa wording ở NT3: HP v4.5.1 ghi "DOT 100% (có ngoại lệ)" và Đ33 §13 mới là nơi nêu ngoại lệ. Đ43 §3 đang viết "Sinh qua 2 DOT cặp, không script rời" là đúng hướng, nhưng bootstrap §11 lại viết deploy script/cron/PG trigger hơi thiên về hạ tầng triển khai. Cần chốt rõ: mọi vận hành sống sau bootstrap phải đi qua DOT; bootstrap/migration chỉ là bước enact một lần.
  • NT12 mới đề xuất chưa đủ chín để đưa lên HP. HP là tầng tối cao, phải là nguyên tắc enforce được. "AI đầu phiên phải đọc PROJECT_MAP.md" hiện mới kiểm được bằng self-declare + prompt ritual, chưa có bằng chứng verify cứng. Nếu đưa vào HP ngay sẽ đụng NT9 "không chắc đúng = sai": không verify được thì không nên nâng lên tầng Hiến pháp.

2) Với Điều 0-G Birth Registry

  • Đ43 §16 nói đếm entities bằng pivot_count() theo Đ26, nhưng §6 bước 3 lại viết đếm entities từ birth_registry group by species. Hai câu này đang vênh cơ chế đếm.
  • Theo Đ0-G v1.0, birth_registry là nơi đếm phổ quát và là đường đếm đơn giản hóa cho entity đang governed. Theo Đ26 v4.0, pivot_count() là phương thức đếm duy nhất cho màn hình/pivot. Đ43 cần chọn một SSOT đếm cho context pack rồi ghi rõ: hoặc lấy trực tiếp từ birth_registry và coi đây là snapshot hạ tầng; hoặc dùng pivot_count() cho các số hiển thị business-facing. Hiện draft viết cả hai.

3) Với Điều 22 Self-healing

  • Kết nối là đúng và nên giữ: H1-H8 fail → fn_log_issue → APR rất hợp Điều 22.
  • Nhưng Đ43 hiện chỉ nói fn_log_issue('dot-context-pack-verify', 'stale_or_drift', manifest_id); cách gọi này không khớp signature fn_log_issue(p_source,p_severity,p_category,p_summary,p_entity_code) đã chuẩn hóa ở Đ35 v5.1. Nếu giữ wording hiện tại, agent rất dễ implement sai.

4) Với Điều 26 Pivot Law

  • Như trên: mâu thuẫn nhỏ nhưng quan trọng giữa pivot_count() và birth_registry direct count.
  • Khuyến nghị: PROJECT_MAP.md và ENTITIES_OVERVIEW.md nên phân 2 lớp số liệu:
    • system snapshot count: lấy từ birth_registry
    • UI/business pivot count: lấy qua pivot_count() nếu cần hiển thị theo pivot semantics
  • Nếu không muốn phức tạp, chọn 1 đường duy nhất là birth_registry cho Đ43 và bỏ câu pivot_count() khỏi §16.

5) Với Điều 35 v5.1 DOT Governance

Có 4 chỗ chưa khớp precedent Đ35 v5.1:

  1. trigger_type = 'cron+on_demand+on_event' không khớp seed dot_trigger_types của Đ35 (cron, event, on-deploy, on-demand, manual, one-off). Không có enum kiểu chuỗi cộng dồn.
  2. coverage_status = 'full' không khớp enum Đ35 (complete, partial, orphan, phantom, deprecated).
  3. trigger_source ở context_pack_manifest là telemetry/runtime source, không phải dot_operations cũng không nên nhầm với dot_trigger_types. Nếu dùng CHECK tự do thì được, nhưng phải gọi đúng bản chất; hiện comment FK dot_operations or dedicated lookup gây nhập nhằng.
  4. _dot_origin VARCHAR(64) NOT NULL DEFAULT 'unknown' khớp pattern Đ35, điểm này đúng và nên giữ.

6) Với Điều 41 VPS Deploy

  • Ý tưởng on-deploy trigger là hợp lý, nhưng phải khớp hành lang Đ41: deploy trên VPS dùng lock + atomic swap + known-good rollback. Đ43 hiện thêm on-deploy build context pack sau deploy nhưng chưa nói chạy ở release nào và ghi vào path nào khi app-production/current vừa swap. Nếu build context pack chạy đồng thời với deploy watch, có thể tạo race read path cũ/path mới.
  • Khuyến nghị: on-deploy của Đ43 không build inline trong deploy critical path; chỉ phát event/queue. Worker build chạy sau khi Đ41 Bước 6.5 đã PASS is_known_good=true, hoặc ít nhất sau symlink swap + smoke pass.

7) Với KB Protection / kb_documents trigger stack

  • Không thấy xung đột trực tiếp về logic, vì KB Protection đang ở DB incomex_metadata và trigger hiện hữu là transparent (trg_kb_truncation_guard, snapshot, audit), không block write.
  • Nhưng có rủi ro loop và write amplification nếu dùng trigger on-law-enact trực tiếp trên kb_documents rồi chính context-pack mirror lại ghi vào knowledge/current-state/context-pack/*, vì mọi write vẫn đi qua audit/history stack. Không loop theo path nếu filter đúng knowledge/dev/laws/%, nhưng sẽ tăng history snapshot đáng kể.
  • Kết luận: không conflict cứng, nhưng phải thiết kế trigger theo kiểu NOTIFY-only + path filter chặt + debounce, tuyệt đối không build synchronous bên trong trigger.

C2 — Schema PG

1) UNIQUE(checksum_sha256) trên context_pack_manifest

  • Có rủi ro false block, vì hai lần build khác generated_at/trigger_source nhưng output 8 file giống hệt có thể cho cùng checksum. Nếu mục tiêu là idempotent storage thì được; nhưng nếu mục tiêu là audit mọi lần build thì UNIQUE này chặn mất run hợp lệ.
  • Cần chốt semantics:
    • nếu manifest là mỗi lần build 1 row, thì KHÔNG UNIQUE checksum_sha256;
    • nếu manifest là mỗi snapshot nội dung duy nhất 1 row, thì cần preflight dedup và một bảng/log khác để ghi execution attempts.
  • Với wording hiện tại §8 verify dùng "manifest row mới nhất ≤ 6h" ⇒ hệ thống đang ngầm coi mỗi run nên có row riêng. Vậy UNIQUE checksum toàn cục là không phù hợp.

Patch đề xuất: bỏ UNIQUE toàn cục, thay bằng index thường trên checksum; hoặc tạo bảng context_pack_runs riêng nếu muốn log executions.

2) UNIQUE(manifest_id, section_name)

  • Constraint này hợp lý, nhưng đang ngầm yêu cầu mỗi manifest phải có đúng 1 tên section canonical. Như vậy section names phải được chuẩn hóa bằng enum/CHECK, không nên để text tự do.
  • Nếu không chuẩn hóa, typo project_map vs project-map sẽ tạo section thiếu/section thừa mà schema vẫn pass.

Patch đề xuất: thêm CHECK section_name IN (...) cho 8 tên chuẩn.

3) _dot_origin VARCHAR(64) NOT NULL DEFAULT 'unknown'

  • Đúng precedent Đ35 v5.1. Nên giữ nguyên.
  • Tuy nhiên để đồng bộ naming với Đ35, nên dùng TEXT NOT NULL DEFAULT 'unknown' thay vì VARCHAR(64) trừ khi có lý do business rõ cho 64 ký tự.

4) trigger_source nên CHECK hay FK?

  • Tôi không khuyến nghị FK vào dot_operations vì đây không phải operation.
  • Giữa CHECK và bảng lookup riêng, tôi nghiêng về bảng lookup riêng context_trigger_sources nếu Đ43 muốn mở rộng về sau (ví dụ manual_repair, rebuild_after_restore, verify_repair).
  • Nếu muốn giữ gọn, CHECK 5 giá trị cũng chấp nhận được. Nhưng với precedent Đ35 là mọi enum quản trị đều đưa vào reference table, lookup table sạch hơn.

Patch đề xuất: tạo bảng context_trigger_sources(code TEXT PRIMARY KEY, name TEXT NOT NULL) và FK từ manifest.

5) trigger_type = 'cron+on_demand+on_event'

  • Sai pattern Đ35 v5.1 §4.1. Đây không phải enum hợp lệ.
  • Precedent đúng là 1 DOT = 1 trigger_type chính, còn trigger phụ/dual-trigger/đa nguồn nên đẩy vào extra_metadata hoặc bảng junction.

Patch đề xuất:

  • trigger_type='cron' cho build DOT vì cron là trigger nền chính
  • thêm extra_metadata = {"secondary_triggers":["on-demand","on-deploy","event"]}
  • hoặc tạo bảng dot_trigger_bindings(dot_code, trigger_source_code) nếu muốn chuẩn hóa thật.

6) coverage_status = 'full'

  • Sai enum theo Đ35. Phải là complete.

7) H5 PROJECT_MAP.md > 20KB = WARN nhưng §7 trần 15KB

  • Đây là mâu thuẫn nội bộ thật sự.
  • Nếu trần pháp lý là 15KB thì >15KB đã phải WARN hoặc FAIL, không thể đợi 20KB mới WARN.

Patch đề xuất:

  • >15KB = WARN, >20KB = CRITICAL/FAIL build
  • hoặc sửa §7 trần cứng thành 20KB nếu muốn nới thực dụng. Tôi nghiêng phương án 2 ngưỡng.

C3 — Flow 8 bước

1) Advisory lock pg_advisory_lock(43001)

  • Tôi không tìm thấy bằng chứng trong Agent Data rằng lock id 43001 đã được dùng ở nơi khác. Vì vậy chưa thể xác nhận “không đụng lock nào đang dùng”. Theo NT9, không chắc thì không được khẳng định an toàn.
  • Dùng số đơn lẻ cũng kém self-documenting.

Patch đề xuất: dùng cặp khóa namespace + object, ví dụ pg_advisory_lock(43, 1) cho build và pg_advisory_lock(43, 2) cho verify; hoặc derive từ hash ổn định của string 'context_pack_build'.

2) Atomic swap bước 7 hiện không atomic xuyên FS + PG + KB API

Đây là blocker chính.

Flow hiện tại:

  1. mv temp → live
  2. INSERT manifest + sections
  3. upload KB mirror

Nếu bước 3 fail sau 1 và 2 thì hệ thống ở trạng thái dirty:

  • filesystem mới đã live
  • DB manifest ghi thành công
  • KB mirror stale/missing
  • verify H4 có thể WARN/CRITICAL ngay sau build thành công

3) Bước 6 “Fail any → rollback” chưa định nghĩa rollback cho mv

  • Rollback PG transaction được.
  • Rollback KB upload có thể retry hoặc delete.
  • Nhưng mv đã swap live thì rollback cần backup old path hoặc symlink swap 2-phase, không thể chỉ nói chung chung.

Thiết kế sửa đề xuất

Dùng 2-phase publish + compensation, không tuyên bố atomic giả.

Thứ tự mới:

  1. build vào context-pack.tmp/<build_id>/
  2. validate toàn bộ
  3. upload KB mirror vào path staging knowledge/current-state/context-pack-staging/<build_id>/...
  4. mở transaction PG, insert manifest với publish_status='staging', insert sections
  5. publish filesystem bằng symlink swap current -> build_id hoặc rename dir kèm backup previous
  6. promote KB staging → live (copy/rename logical nếu tool cho phép; nếu không thì upload live sau khi FS publish)
  7. cập nhật manifest publish_status='live', published_at=now()
  8. nếu bước 6 fail: giữ manifest kb_mirror_status='failed', tạo issue + retry DOT; không rollback FS live, vì rollback chéo hệ không đáng tin. Hệ thống phải honest rằng đây là publish-partial cần repair.

Điểm mấu chốt: bỏ câu "rollback toàn bộ" vì không đúng thực tế. Thay bằng transactional where possible, compensating where impossible.

C4 — Dual-trigger

Đ43 đúng khi muốn 5 trigger, nhưng draft hiện thiếu lớp chống storm/coalesce.

Rủi ro thật

  1. Enact 10 luật/1 phút → 10 event build liên tiếp.
  2. Seed 18 dot operations hoặc bulk register DOT → nhiều INSERT dot_tools fire liên tiếp.
  3. on-law-enact + on-dot-register + cron có thể chồng cùng lúc, tạo queue build trùng input.
  4. Nếu build lại chính file context pack và verify nhìn vào manifest latest, các run chồng nhau rất dễ báo stale/drift giả.

Patch kiến trúc

Tách event capture khỏi build execution.

Đề xuất thêm bảng hàng đợi/coalesce:

CREATE TABLE context_pack_event_queue (
  id BIGSERIAL PRIMARY KEY,
  event_type TEXT NOT NULL,
  event_key TEXT NOT NULL,
  source_ref TEXT,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  status TEXT NOT NULL DEFAULT 'pending',
  coalesce_window_sec INT NOT NULL DEFAULT 60,
  UNIQUE (event_type, event_key, status)
    DEFERRABLE INITIALLY IMMEDIATE
);

Nhưng còn gọn hơn là thêm bảng request:

CREATE TABLE context_pack_requests (
  id BIGSERIAL PRIMARY KEY,
  requested_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  trigger_source TEXT NOT NULL REFERENCES context_trigger_sources(code),
  dedupe_key TEXT NOT NULL,
  status TEXT NOT NULL CHECK (status IN ('pending','running','done','skipped','failed')),
  UNIQUE (dedupe_key, status) WHERE status IN ('pending','running')
);

Logic:

  • trigger chỉ INSERT request với dedupe_key = date_trunc('minute', now()) + ':' + trigger_source hoặc hash theo affected object family
  • worker 1 phút/lần lấy 1 request pending mới nhất, gộp các request còn lại trong cửa sổ 60–120 giây thành skipped_coalesced
  • build xong ghi coalesced_events_count

Kết luận C4

  • Có, bắt buộc cần debounce/coalesce.
  • Trigger PG phải là NOTIFY/queue only, không gọi build trực tiếp.

C5 — NT12 + AP-24

1) AI self-report “đã đọc” có verify được không?

  • Không verify cứng nếu chỉ dựa vào câu declare trong response đầu.
  • Bởi vậy NT12 ở dạng draft hiện nay là quy định đạo đức/quy trình, chưa phải nguyên tắc Hiến pháp enforceable.

2) Có cơ chế enforce cứng nào không?

Có thể làm enforce mềm có bằng chứng, chưa phải tuyệt đối:

Mức A — Session attestation mềm

  • PROJECT_MAP.md chứa header manifest_id, checksum_sha256, generated_at
  • prompt bootstrap bắt agent phải echo đúng 3 giá trị này ở response đầu
  • server/prompt wrapper verify chuỗi đó khớp manifest latest
  • điều này chỉ chứng minh đã nhìn thấy header, chưa chứng minh đọc hiểu toàn bộ

Mức B — Checkpoint theo task class

  • nếu task có tag law|schema|deploy|dot, wrapper buộc đọc thêm section tương ứng và echo section checksum
  • sai checksum → chặn tiếp tục

Mức C — Tool-gated context session

  • mọi task hệ thống phải bắt đầu bằng tool call lấy v_context_pack_latest hoặc document PROJECT_MAP.md
  • không có access log/tool trace tương ứng → fail compliance

Mức C là enforce mạnh nhất khả thi hiện nay.

3) Có nên downgrade NT12 khỏi HP?

  • Có. Tôi khuyến nghị không amend HP lên NT12 trong cùng đợt enact Đ43.
  • Hãy đưa NT12 xuống thành clause của Đ43 §13 hoặc một "Operating Principle" cấp luật trước. Khi có tool-gated compliance metrics đủ 2–4 tuần, lúc đó mới xem xét nâng lên HP.

4) AP-24 có nên thêm không?

  • Có, vì anti-pattern là bài học hành vi, không đòi hỏi enforce tuyệt đối như Hiến pháp.
  • Wording AP-24 nên gắn với task hệ thống trọng yếu thay vì mọi chat nhỏ, để tránh overreach.

C6 — Điểm gãy triển khai

1) Atomic publish + KB mirror mismatch

Đây là điểm gãy số 1. Không sửa bước 7 thì bản đầu tiên rất dễ dirty state.

2) Trigger storm từ on-law-enact / on-dot-register

Đặc biệt seed/bulk register sẽ spam build nếu không có debounce.

3) PROJECT_MAP.md quá dense cho LLM

  • Mục tiêu 30 giây là đúng, nhưng 1 file gánh big picture + entrypoints + missions + recent changes + anti-patterns + health rất dễ thành tạp chí tổng hợp.
  • Nên tách thành PROJECT_MAP.md (executive 8–12 KB) + PROJECT_MAP_DEV.md / PROJECT_MAP_ARCH.md hoặc ít nhất project-map.json làm data máy, còn markdown chỉ giữ tóm tắt.

4) Git commit lookup không chắc luôn tồn tại

  • Nếu VPS path chạy không phải git worktree sạch, git rev-parse HEAD có thể fail.
  • Draft §6 bước 1 nói precheck verify git clean, nhưng context pack là hạ tầng sống; không nên chết cứng chỉ vì runtime path không còn .git.
  • Cần fallback: read release metadata, REVISION file, hoặc vps_deploy_log.release_path / known-good hash theo Đ41.

5) KB mirror write amplification / kb_documents_history bloat

  • 8 files × mỗi 3h = 64 write/ngày nếu luôn update đầy đủ; cộng history snapshot trước UPDATE/DELETE sẽ tăng tương ứng.
  • Chưa phải quá lớn, nhưng nếu luôn upload dù checksum không đổi thì bloat là vô ích.

Patch: chỉ mirror file nào checksum đổi; file không đổi thì skip upload + skip history churn.

C7 — Patch cụ thể

Patch 1 — Sửa NT12 / HP wording

Thay §3.1 hiện tại bằng:

### §3.1 — Nguyên tắc vận hành AI theo Đ43 (KHÔNG amend HP trong v1.0)

Mọi AI/agent khởi động phiên mới và chuẩn bị thực hiện task hệ thống thuộc nhóm luật / DOT / schema / deploy / code write
BẮT BUỘC đọc `PROJECT_MAP.md` trước khi hành động.

Cơ chế enforce giai đoạn v1.0:
1. Prompt CHECKPOINT bắt buộc gọi tool đọc context pack latest
2. Response đầu phải declare `manifest_id`, `generated_at`, `checksum_sha256`
3. Task luật/DOT/schema phải declare thêm section checksum tương ứng
4. Thiếu CHECKPOINT hoặc declare sai → AP-24 fire

Sau tối thiểu 30 ngày có compliance metrics ổn định mới được đề xuất nâng thành NT12 Hiến pháp.

Patch 2 — Chuẩn hóa schema context_pack_manifest

CREATE TABLE context_trigger_sources (
  code TEXT PRIMARY KEY,
  name TEXT NOT NULL
);

INSERT INTO context_trigger_sources(code, name) VALUES
  ('cron', 'Lịch định kỳ'),
  ('on_demand', 'Khi yêu cầu'),
  ('on_deploy', 'Sau deploy'),
  ('on_law_enact', 'Luật thay đổi'),
  ('on_dot_register', 'DOT registry thay đổi');

CREATE TABLE context_pack_manifest (
  id BIGSERIAL PRIMARY KEY,
  generated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  published_at TIMESTAMPTZ,
  git_commit VARCHAR(40) NOT NULL,
  trigger_source TEXT NOT NULL REFERENCES context_trigger_sources(code),
  law_count INT NOT NULL,
  dot_count INT NOT NULL,
  entity_count BIGINT NOT NULL,
  species_count INT NOT NULL,
  db_count INT NOT NULL,
  total_size_bytes BIGINT NOT NULL,
  section_count INT NOT NULL CHECK (section_count = 8),
  checksum_sha256 VARCHAR(64) NOT NULL,
  publish_status TEXT NOT NULL CHECK (publish_status IN ('staging','live','failed')) DEFAULT 'staging',
  kb_mirror_status TEXT NOT NULL CHECK (kb_mirror_status IN ('pending','live','failed')) DEFAULT 'pending',
  health_status VARCHAR(16) NOT NULL CHECK (health_status IN ('healthy','warn','stale','fail')),
  generation_duration_ms INT,
  _dot_origin TEXT NOT NULL DEFAULT 'unknown'
);

CREATE INDEX idx_cpm_generated_at ON context_pack_manifest(generated_at DESC);
CREATE INDEX idx_cpm_checksum ON context_pack_manifest(checksum_sha256);

Patch 3 — Chuẩn hóa context_pack_sections

CREATE TABLE context_pack_sections (
  id BIGSERIAL PRIMARY KEY,
  manifest_id BIGINT NOT NULL REFERENCES context_pack_manifest(id) ON DELETE CASCADE,
  section_name TEXT NOT NULL CHECK (
    section_name IN (
      'project_map','laws_index','dot_registry','entities_overview',
      'db_map','red_zones','architecture_mmd','project_map_json'
    )
  ),
  file_path TEXT NOT NULL,
  kb_document_path TEXT,
  size_bytes INT NOT NULL CHECK (size_bytes >= 0),
  line_count INT NOT NULL CHECK (line_count >= 0),
  checksum_sha256 VARCHAR(64) NOT NULL,
  UNIQUE(manifest_id, section_name)
);

Patch 4 — Sửa Đ35 field values tại §8.1 và §8.2

Thay bảng DOT build bằng:

  • trigger_type = cron
  • coverage_status = complete
  • thêm extra_metadata.secondary_triggers = ["on-demand","on-deploy","event"]

Thay bảng DOT verify bằng:

  • trigger_type = cron
  • coverage_status = complete
  • thêm extra_metadata.secondary_triggers = ["on-demand"]

Patch 5 — Sửa H5 size thresholds

| H5 | `PROJECT_MAP.md` size | > 15KB = WARN; > 20KB = CRITICAL |

Và giữ §7 trần mục tiêu 15KB như target thiết kế.

Patch 6 — Sửa bước 2 lock

2. **Bước 2 — LOCK:** Acquire advisory lock namespace Đ43:
   - build = `pg_try_advisory_lock(43, 1)`
   - verify = `pg_try_advisory_lock(43, 2)`
   Nếu không lấy được lock → ghi log `coalesced_skip`, exit 0.

Dùng try_ thay vì lock cứng để tránh kẹt hàng đợi.

Patch 7 — Viết lại bước 7 theo compensation thật

7. **Bước 7 — PUBLISH (2-phase + compensating action):**
   a. Upload KB mirror vào staging path `knowledge/current-state/context-pack-staging/<build_id>/`
   b. INSERT manifest + sections với `publish_status='staging'`, `kb_mirror_status='pending'`
   c. Promote filesystem bằng symlink swap `current -> <build_id>` (giữ `previous -> <old_build_id>`)
   d. Promote KB staging → live hoặc upload live nếu content changed
   e. UPDATE manifest SET `publish_status='live'`, `kb_mirror_status='live'`, `published_at=now()`
   f. Nếu (d) fail: giữ FS live, UPDATE manifest `kb_mirror_status='failed'`, gọi `fn_log_issue(...)`, tạo APR/retry job

Patch 8 — Thay wording rollback ở bước 6

Thay câu: Fail any → rollback (xóa temp, giữ bản cũ)

Bằng:

Fail trước publish filesystem → xóa temp, giữ bản live cũ.
Fail sau publish filesystem → không tuyên bố rollback toàn cục; ghi `publish_partial`, giữ `previous` để DOT repair hoặc operator rollback có kiểm soát.

Patch 9 — Bổ sung debounce/coalesce

CREATE TABLE context_pack_requests (
  id BIGSERIAL PRIMARY KEY,
  requested_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  trigger_source TEXT NOT NULL REFERENCES context_trigger_sources(code),
  dedupe_bucket TIMESTAMPTZ NOT NULL,
  status TEXT NOT NULL CHECK (status IN ('pending','running','done','skipped','failed')) DEFAULT 'pending',
  detail JSONB NOT NULL DEFAULT '{}'
);

CREATE UNIQUE INDEX uq_context_pack_requests_open
ON context_pack_requests(trigger_source, dedupe_bucket)
WHERE status IN ('pending','running');

Logic luật hóa: event triggers chỉ INSERT request với dedupe_bucket = date_trunc('minute', now()); worker xử lý request mới nhất mỗi 60s, các request dư đánh dấu skipped với reason coalesced.

Patch 10 — Sửa liên kết Đ22 / fn_log_issue

Thay ví dụ verify fail bằng wording đúng signature:

SELECT fn_log_issue(
  'dot-context-pack-verify',
  'critical',
  'context_pack_stale_or_drift',
  format('Manifest %s stale/drift or KB mirror mismatch', v_manifest_id),
  v_manifest_id::text
);

Patch 11 — Chốt đường đếm với Đ0-G / Đ26

Đề xuất wording thay §16 dòng Đ26:

| Đ26 Pivot | Context pack có thể tham chiếu pivot definitions cho màn hình phân tích; riêng `entity_count` snapshot chuẩn của Đ43 lấy từ `birth_registry` để giữ 1 đường đếm hạ tầng đơn giản, ổn định, không phụ thuộc lớp hiển thị. |

Patch 12 — Giảm write bloat KB

Bổ sung vào bước 7: chỉ mirror file nào checksum_sha256 changed; file không đổi thì giữ nguyên KB doc cũ, chỉ cập nhật manifest row.

Blockers cần fix TRƯỚC khi ban hành

  1. CRITICAL — trigger_type='cron+on_demand+on_event' và coverage_status='full' không khớp enum/pattern Đ35 v5.1; nếu không sửa sẽ tạo precedent xấu và có thể fail register/backfill.
  2. CRITICAL — Bước 7 đang tuyên bố atomic sai sự thật giữa filesystem + PG + KB API; phải đổi sang 2-phase publish + compensating action.
  3. HIGH — NT12 chưa enforce được nhưng draft đòi amend HP ngay; nên hạ xuống clause của Đ43 trước.
  4. HIGH — UNIQUE(checksum_sha256) trên manifest không khớp semantics “mỗi build một row”; cần bỏ hoặc tách bảng run riêng.
  5. HIGH — Thiếu debounce/coalesce cho 5 trigger sources; bulk event sẽ gây storm.
  6. HIGH — Mâu thuẫn H5 (>20KB WARN) với §7 (15KB trần) phải sửa trước khi agent implement.

Điểm mạnh của draft

  • Chạm đúng pain thật: context loss đầu phiên là vấn đề gốc, không phải tiểu tiết.
  • Tư duy 3 lớp Meta-Incomex / System / Code rất đúng với thực trạng Incomex và bù khoảng trống của tool thị trường.
  • Biết học precedent Đ35 v5.1: tránh partial row, có health checks, có grace period, có self-healing linkage.

Khuyến nghị cuối

APPROVE WITH CHANGES.

Bản này nên vào Round 2 ngắn sau khi apply 6 patch bắt buộc:

  1. bỏ amend HP/NT12 khỏi đợt enact v1.0,
  2. chuẩn hóa enum theo Đ35,
  3. sửa bước 7 thành 2-phase publish,
  4. bỏ/đổi UNIQUE(checksum_sha256),
  5. thêm debounce/coalesce queue,
  6. sửa mâu thuẫn size thresholds + chốt 1 đường đếm với Đ0-G/Đ26.

Sau khi vá 6 điểm này, tôi nghiêng về khả năng ban hành được mà không cần rework kiến trúc gốc.