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

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

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

Gói amend đi đúng hướng hiến định và đóng được lỗ hổng “sửa bug DOT canonical đã enacted”, nhưng Round 1 chưa nên chốt FINAL vì còn 4 điểm kỹ thuật phải siết: schema Đ32 đang mơ hồ giữa code/action JSONB, thứ tự enact trong phần phụ thuộc đang viết ngược logic, retrofit 14 ngày vs 90 ngày chưa khóa rõ scope, và §4.1 Đ22 cần giảm false-positive/false-ban ở các pattern bash hợp lệ.

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

P1 — Đ41 v1.0 → v1.1: mở rộng `ops-code/`

Điểm: 8.9/10

Triết lý đạt:

Đóng đúng lỗ hổng lớn nhất của Đ41 hiện hành: /opt/incomex/dot/bin/ đang là vùng “vô chủ”, không thuộc app-dev/, app-production/, infra/ dù thực tế lại chứa canonical vận hành sống. P1 biến DOT bash/SQL migration/cron script thành một lớp được gọi tên và chịu quy trình riêng, phù hợp tinh thần Đ41 §2, §3, §5 và Hiến pháp NT9, NT10, NT13.
Mô hình “không sửa thẳng file live, phải backup → patch → dry-run → commit+log” nhất quán với Đ41 §5, đặc biệt NT-VPS-2, 3, 4, 5, 8.

Thiếu / cần siết:

Cụm “Path mặc định: /opt/incomex/dot/bin/” là đúng vận hành, nhưng nên viết rõ ops-code/ là layer logic, không đồng nghĩa 1 thư mục duy nhất. Nếu sau này có migration SQL ở knowledge/dev/laws/dieu43-migrations/ hoặc cron wrapper ở deploy/, luật hiện tại dễ bị hiểu nhầm rằng chỉ /opt/incomex/dot/bin/ mới là ops-code.
git commit trong repo agent-data-repo là hợp ý audit, nhưng wording hiện tại dễ xung đột với chính Đ41 vì repo chạy thật trên VPS có thể không phải lúc nào cũng cùng repo tài liệu. Nên viết thành “commit vào repo SSOT tương ứng của artifact được sửa”.
vps_deploy_log kind='ops-code' chưa có cột kind trong schema Đ41 §8. Nếu không amend luôn schema log, câu này thành text-only, vi phạm NT10.

Wording cần sửa:

Thay “Path mặc định: /opt/incomex/dot/bin/” bằng: “/opt/incomex/dot/bin/ là canonical path mặc định cho DOT bash live; các artifact vận hành liên quan có thể nằm ở path khác nhưng vẫn thuộc layer ops-code/ nếu được registry hóa trong DOT/Đ41`.”
Thay “git commit trong repo agent-data-repo” bằng: “git commit vào repo SSOT chứa artifact được sửa; nếu artifact live chưa nằm trong repo, phải tạo audit snapshot bắt buộc.”
Đổi “ghi vps_deploy_log với kind='ops-code'” thành một trong hai hướng rõ ràng:
1. Amend schema: thêm cột deploy_kind TEXT NOT NULL DEFAULT 'app' vào vps_deploy_log; seed 'ops-code', 'app', 'infra'.
2. Hoặc không amend schema: ghi deploy_kind=ops-code trong notes/smoke_evidence có cấu trúc JSONB.

Đề xuất cụ thể:

Thêm §2.x: định nghĩa ops-code/ là logical deployment class gồm DOT canonical bash scripts, migration SQL, cron wrappers, và tool hỗ trợ vận hành đã đăng ký.
Thêm §5.8.1: ops-code không dùng FAST/FULL, nhưng vẫn phải phân loại Loại B / Loại C nếu đụng data/schema thật.
Thêm §8 amend nhỏ cho vps_deploy_log nếu muốn dùng kind='ops-code' như một trường enforceable.

P2 — Đ32 v1.0 → v1.1: whitelist chuyển sang PG-native

Điểm: 7.8/10

Triết lý đạt:

Đây là patch quan trọng nhất về mặt Hiến pháp: đưa whitelist khỏi bash hardcode sang PG-native đúng NT4, NT10, NT13.
Việc bổ sung edit_dot_file, amend_law, fix_repair_dot là cần thiết để mở đường hợp pháp cho flow sửa DOT enacted, đồng thời xóa nghịch lý hiện tại: Đ35 gọi tên fix_repair_dot nhưng engine APR lại không biết loại request này.

Thiếu / blocker kỹ thuật:

Mâu thuẫn schema gốc: Đ32 §3 hiện mô tả approval_requests.proposed_action là jsonb, không phải text code. Patch lại ghi “FK reference từ approval_requests.proposed_action” sang apr_action_types. Nếu giữ nguyên jsonb thì FK kiểu này không khả thi. Đây là blocker lớn nhất của cả gói.
request_type ở Đ32 gốc là text field; patch muốn PG-native là đúng, nhưng chưa nói rõ sẽ:
- giữ approval_requests.request_type TEXT + FK tới apr_request_types.request_code, hay
- đổi tên cột, hay
- tách code/value.
Chưa định nghĩa status domain của 2 bảng mới. Nếu đã dùng bảng quản trị thì nên khóa status về active/deprecated/retired hoặc dùng enum/reference table, không để text tự do.
Chưa nói rõ behavior khi legacy row có request_type/action_code không còn active. Nếu dùng FK cứng + seed thiếu lịch sử, có nguy cơ khóa cứng APR cũ.

Schema & data integrity review cho 2 bảng mới:

Đề xuất schema tối thiểu an toàn:

CREATE TABLE apr_action_types (
  action_code TEXT PRIMARY KEY,
  description TEXT NOT NULL,
  handler_ref TEXT NOT NULL,
  status TEXT NOT NULL CHECK (status IN ('active','deprecated','retired')),
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  retired_at TIMESTAMPTZ NULL
);

CREATE TABLE apr_request_types (
  request_code TEXT PRIMARY KEY,
  description TEXT NOT NULL,
  default_action_code TEXT NULL REFERENCES apr_action_types(action_code) ON UPDATE CASCADE ON DELETE RESTRICT,
  status TEXT NOT NULL CHECK (status IN ('active','deprecated','retired')),
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  retired_at TIMESTAMPTZ NULL
);

Và amend approval_requests theo hướng 2 lớp:

ALTER TABLE approval_requests
  ADD COLUMN request_type_code TEXT,
  ADD COLUMN proposed_action_code TEXT;

ALTER TABLE approval_requests
  ADD CONSTRAINT fk_apr_request_type
    FOREIGN KEY (request_type_code)
    REFERENCES apr_request_types(request_code)
    ON UPDATE CASCADE ON DELETE RESTRICT;

ALTER TABLE approval_requests
  ADD CONSTRAINT fk_apr_action_type
    FOREIGN KEY (proposed_action_code)
    REFERENCES apr_action_types(action_code)
    ON UPDATE CASCADE ON DELETE RESTRICT;

Quan điểm FK / NOT NULL / CASCADE:

PK + NOT NULL: bắt buộc cho hai bảng mới.
FK từ approval_requests sang type tables: nên có, nhưng không bật NOT NULL ngay cho legacy nếu chưa backfill toàn bộ APR cũ.
ON UPDATE CASCADE: hợp lý vì code có thể được sửa typo hiếm hoi.
ON DELETE CASCADE: không hợp lý vì xóa một type không được kéo sập lịch sử APR. Nên dùng ON DELETE RESTRICT hoặc soft-retire qua status='retired'.
Legacy safety: tuyệt đối không delete code đã từng được APR tham chiếu; chỉ retire. Đây là cách tránh khóa cứng legacy APR mà vẫn giữ referential integrity.

Wording cần sửa:

Đổi “FK reference từ approval_requests.proposed_action” thành: “bổ sung proposed_action_code (TEXT FK), còn proposed_action tiếp tục giữ payload JSONB chi tiết”.
Đổi “VALID_REQUEST_TYPES cũng chuyển vào PG table apr_request_types” thành: “approval_requests.request_type_code FK → apr_request_types.request_code; payload business vẫn nằm ở các cột hiện hành.”

Đề xuất cụ thể:

Bổ sung P2a migration: thêm 2 cột code vào approval_requests, backfill từ text legacy, sau đó mới sửa dot-apr-propose / dot-apr-execute.
Bổ sung P2b seed sequencing:
1. Tạo bảng type
2. Seed action types
3. Seed request types
4. Backfill APR legacy
5. Enable runtime read
Bổ sung P2c compatibility rule: status='retired' không cho APR mới dùng, nhưng vẫn cho APR cũ join/hiển thị được.

P3 — Đ35 v5.1 → v5.2: flow `fix_repair_dot` end-to-end

Điểm: 9.1/10

Triết lý đạt:

P3 là lõi pháp lý đúng nhất của gói: biến một nhu cầu vận hành có thật thành flow chuẩn hóa Detect → Propose → Approve → Apply → Verify → Close, khớp trực tiếp tinh thần Đ22, Đ32, Đ35, Đ41.
Sửa đúng vi phạm NT10 hiện hữu của Đ35 v5.1: text có nhắc fix_repair_dot nhưng engine/runtime chưa có corresponding entity.
Thêm paired test script cho DOT canonical là nước đi rất đúng theo NT12 và bài học Đ43 rev 2: phải rà 3 tầng code, SQL DDL, SQL data.

Thiếu / cần siết:

P3 hiện gọi “payload gồm diff cũ→mới, root cause, test plan” là tốt, nhưng chưa bắt buộc rõ 3 tầng regression evidence:
1. shell behavior,
2. SQL compile/DDL validity,
3. data-path validation.
VERIFY: chạy lại cho APR test là đúng, nhưng còn thiếu quy định test fixture cho bug silent-fail. Với loại lỗi “gate trả 0 câm”, phải bắt buộc có test tái hiện cả stderr/stdout/exit code trước và sau sửa.
Clause “DOT legacy đã enacted trước §6 này vẫn áp. KHÔNG có cửa bypass.” là đúng, nhưng chưa nói rõ không hồi tố theo kiểu buộc paired test ngay lập tức. Nếu không, luật dễ tự mâu thuẫn với chính retrofit 90 ngày.

Wording cần sửa:

Trong bước APPLY thêm: “Bắt buộc lưu artifact before/after gồm file patch, stdout, stderr, exit code, và nếu có SQL thì phải có EXPLAIN/compile check hoặc statement validation tương ứng.”
Trong §5.3 đổi thành: “Mọi DOT bash canonical enacted mới từ ngày amend có hiệu lực phải có paired test ngay; DOT legacy enacted trước ngày đó được retrofit trong 90 ngày theo §6.7/§5.3.”

Đề xuất cụ thể:

Thêm một clause con §6.4.1: bug DOT thuộc 3 lớp bắt buộc verify riêng: shell semantics / SQL DDL / SQL data.
Thêm yêu cầu rollback proof: backup phải kiểm chứng được restore, không chỉ tồn tại .bak-{session}.
Ghi rõ edit_dot_file chỉ áp cho canonical live artifact đã registry hóa; các chỉnh sửa luật đi theo amend_law riêng, tránh nhập nhằng phạm vi.

P4 — Đ22 v1.0 → v1.1: cấm silent-fail pattern

Điểm: 8.4/10

Triết lý đạt:

P4 đúng tinh thần Đ22 nhất: biến triết lý “phơi bày ra ánh sáng” thành rule kỹ thuật enforceable. Đây là chỗ gói amend chuyển từ khẩu hiệu sang cơ chế.
Cặp dot-ops-silent-fail-scan + dot-ops-silent-fail-repair rất đúng NT12.

Thiếu / rủi ro false positive / false ban:

Pattern (a) 2>/dev/null: wording hiện tại “ở ngữ cảnh gate/validation/SQL query” là gần đúng nhưng chưa machine-checkable. Regex thuần văn bản sẽ false-positive cao với các probe hợp lệ như command -v foo 2>/dev/null || echo 'not found' hoặc test -e ... 2>/dev/null trong block không quyết định state change.
Pattern (b) || true sau lệnh thay đổi trạng thái: đúng hướng, nhưng cần định nghĩa thế nào là “lệnh thay đổi trạng thái”. Regex text khó phân biệt grep ... || true với psql -c 'UPDATE ...' || true. Nếu scan quá đơn giản sẽ bắt nhầm nhiều đoạn hợp lệ.
Pattern (c) set +e không có cặp set -e kèm comment lý do: đúng, nhưng có một số shell block hợp lệ dùng subshell/temporary disable errexit trong vùng thu thập evidence. Nếu luật cấm tuyệt đối sẽ ban nhầm cả mẫu kỹ thuật an toàn.

Đánh giá DOT scan regex:

Nếu chỉ regex, false-positive trung bình đến cao.
Nếu scan theo risk-tier + heuristic + allowlist comment marker, false-positive sẽ chấp nhận được.

Wording cần sửa:

Đổi “Cấm 3 pattern sau” thành “Cấm 3 pattern sau khi chúng ảnh hưởng quyết định control-flow, gate, validation, mutation hoặc che khuất lỗi thực thi.”
Thêm cơ chế ngoại lệ có audit marker, ví dụ:
- # silent-fail-allow: probe-only
- # errexit-allow: bounded-capture
Thay “cron daily, quét toàn bộ /opt/incomex/dot/bin/**/*.sh” bằng “quét toàn bộ script shell đã registry hóa trong ops-code/; path scanner lấy từ registry hoặc config, không hardcode duy nhất một cây thư mục.”

Đề xuất cụ thể:

Scan nên chấm điểm 3 mức:
1. critical: 2>/dev/null hoặc || true đi kèm psql, UPDATE, DELETE, INSERT, ALTER, cp, mv, rm, file write redirect, hoặc biến quyết định gate.
2. warning: probe-only pattern chưa có annotation.
3. allow: có marker ngoại lệ hợp lệ.
Thêm rule: mọi suppress stderr hợp lệ phải redirect vào biến/log có tên, không được nuốt hoàn toàn. Ví dụ lưu stderr temp file rồi parse.
dot-ops-silent-fail-repair không nên auto-fix toàn diện bằng regex rewrite; chỉ nên tạo APR + patch suggestion, trừ các mẫu cực chắc chắn.

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

NT1 — Làm một lần, dùng mãi

Đạt một phần, cần siết thêm.

P2 đưa whitelist vào PG thay vì hardcode bash là đúng NT1/NT4.
P3 tạo flow chuẩn cho bug DOT enacted là đúng tinh thần reusable.
Nhưng nếu không sửa triệt để schema Đ32 theo mô hình *_code + payload, hệ thống sẽ có hai nguồn chân lý chồng nhau (JSON text và type table), làm NT1 bị thủng.

NT2 — Tự động 100%

Đạt hướng, chưa đủ khóa máy.

P4 có scanner cron là đúng NT2.
P3 có flow verify + rollback là đúng hướng tự động.
Tuy nhiên §4.1 Đ22 hiện vẫn nặng text policy hơn executable rule; cần scan heuristic và annotation rule rõ hơn để máy thực thi ổn định.

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

Đạt.

Gói amend không mở cửa bypass tay; ngược lại còn hợp thức hóa đường DOT cho sửa canonical DOT enacted.
P1 giúp DOT live artifact được kéo vào hành lang Đ41 thay vì vùng xám ngoài luật.

NT4 — Sẵn sàng thay đổi

Đạt mạnh ở P2, nhưng phải đi đến cùng.

Whitelist/request types chuyển vào PG là mẫu NT4 rất đúng.
Scanner P4 nếu hardcode path /opt/incomex/dot/bin/**/*.sh thì lại tái phạm NT4 ở cấp scanner. Nên config/registry hóa path scan.

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

Đạt một phần.

P4 + P3 xây vòng phát hiện → APR → sửa → verify khá đúng.
Nên tránh auto-repair quá rộng ở silent-fail; nên “tự phát hiện mạnh, tự sửa có điều kiện”, để không sinh bug mới.

NT6, NT7, NT8

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

Gói amend chủ yếu ở lớp governance/ops-code, không có dấu hiệu bypass kiến trúc 5 tầng.
Assembly-first được củng cố nhờ P2 PG-native.

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

Đạt rất mạnh.

Chính bối cảnh gói amend sinh ra từ agent dừng đúng vì không có law cover end-to-end.
P3 formalize việc detect, propose, approve, verify trước khi apply; rất hợp NT9.
Cần thêm yêu cầu regression evidence 3 tầng để NT9 được thực thi thật, không chỉ nói.

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

Đạt hướng, chưa hoàn tất.

P2 là patch NT10 quan trọng nhất.
P1 đang có một câu kind='ops-code' nhưng chưa có schema log tương ứng, đây là chỗ text chạy trước PG.
P3 sửa được lỗi “text nhắc fix_repair_dot nhưng PG chưa có entry”.

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

Đạt tương đối.

Nếu P2 tách proposed_action_code khỏi proposed_action JSONB thì rất đẹp: code để enforce, payload để mang chi tiết.
Nếu bắt khai cả code lẫn text lặp lại vô ích thì sẽ vi phạm NT11. Cần cấu trúc hóa rõ vai trò từng cột.

NT12 — DOT theo cặp

Đạt mạnh.

P3 thêm paired test script cho DOT canonical.
P4 thêm DOT scan/repair pair.
Cần làm rõ retrofitting timeline để tránh biến NT12 thành yêu cầu bất khả thi trong ngày enact.

NT13 — Ưu tiên PG native

Đạt mạnh ở P2; chưa chặt ở P4.

PG tables cho action/request types đúng NT13.
Nếu scanner silent-fail chỉ dùng regex shell ad hoc mà không tận dụng registry/config/metadata hiện có thì chưa khai thác hết NT13, dù đây không phải vi phạm nặng.

4. Tương tác giữa 4 Patch

Có xung đột không?

Không có xung đột kiến trúc lớn, nhưng có một lỗi logic ở phần phụ thuộc.

Patch hiện ghi:

P4 kích hoạt nhu cầu → P3
P3 phụ thuộc → P2
P2 phụ thuộc → P1
nhưng kết luận enact P1 → P2 → P3 → P4

Kết luận enact là đúng, sơ đồ giải thích thì đang viết ngược chiều logic triển khai.

Thứ tự enact `P1 → P2 → P3 → P4` có hợp lý không?

Có, đây là thứ tự đúng nhất ở mức law + implementation barrier:

P1 trước để hợp pháp hóa ops-code/ và hành lang deploy/log/backup.
P2 sau để engine APR có vocabulary hợp pháp (edit_dot_file, fix_repair_dot).
P3 sau nữa vì flow fix_repair_dot cần cả hành lang ops-code lẫn type tables APR.
P4 cuối vì chỉ nên cấm mạnh silent-fail sau khi đã có flow sửa hợp pháp để xử lý hàng loạt vi phạm bị scan ra.

Atomic transaction khả thi không?

Không khả thi theo nghĩa DB transaction duy nhất bao trùm toàn gói.

Lý do:

Gói chạm 4 tầng khác nhau: law text, bash/runtime, SQL DDL, SQL data.
Luật có thể enact atomically ở mức “cùng một phiên quyết nghị”, nhưng implementation thực tế phải là release train có barrier, không thể là 1 transaction DB duy nhất.

Mô hình khả thi hơn:

Atomic ở mức governance: ban hành cùng phiên.
Transactional ở mức migration con:
- M1: P2 schema + seed + backfill
- M2: P1 log/schema amend (nếu có) + deploy path registration
- M3: P3 runtime enable
- M4: P4 scan enable ở mode observe → warn → enforce

Khuyến nghị: bật P4 theo 2 pha:

pha 1: detect-only + APR create
pha 2: sau khi batch retrofit 13 DOT legacy xong mới nâng enforcement severity

5. Retrofit clause

§6.7 (14 ngày) + §4.2 (90 ngày) đủ bảo vệ legacy không?

Chưa đủ rõ; về ý tưởng là gần đủ, về wording là còn lệch scope.

14 ngày hợp lý cho việc xóa silent-fail patterns đã biết trên 13 DOT legacy Đ38, vì đây là nhóm bug đã được chỉ mặt đặt tên.
90 ngày hợp lý cho việc bổ sung paired test scripts cho toàn bộ DOT canonical legacy, vì đây là retrofit nặng hơn nhiều, đòi hỏi thiết kế test harness.

Vấn đề: patch hiện làm người đọc dễ hiểu nhầm rằng cùng một tập DOT legacy phải hoàn tất cả hai việc trong hai deadline khác nhau mà không nói rõ scope nào thuộc deadline nào.

Đề nghị wording chuẩn:

14 ngày: remediation bắt buộc cho silent-fail violations đã inventory hóa.
90 ngày: retrofit bắt buộc cho paired test coverage của DOT canonical legacy.
Trong thời gian chờ 90 ngày, DOT legacy vẫn được phép tồn tại nhưng mọi fix mới theo fix_repair_dot phải kèm test hồi quy tối thiểu cho bug đang sửa.

Kết luận: đủ bảo vệ legacy nếu tách scope rõ. Nếu không tách rõ, sẽ gây tranh cãi khi thực thi.

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

6.1 Lỗ hổng lớn nhất chưa đóng hẳn

P2 chưa đóng xong vì schema chưa đủ chặt. Nếu không bổ sung request_type_code và proposed_action_code, luật sẽ lại lặp lỗi kiểu NT10: text nói PG-native nhưng runtime vẫn phải suy luận từ payload.

6.2 Edge case gây side-effect ở P4

2>/dev/null trong probe-only shell hợp lệ có thể bị ban nhầm.
|| true sau lệnh read-only hoặc grep aggregation có thể bị ban nhầm.
set +e trong bounded capture block có thể bị ban nhầm.

=> Cần annotation + risk-tier scanner, không scan regex thô.

6.3 Sequencing của seed + migration cho 13 DOT legacy

Hiện patch mới nói idempotent ON CONFLICT DO NOTHING, nhưng chưa khóa trình tự đủ chặt. Trình tự nên là:

tạo apr_action_types
seed actions
tạo apr_request_types
seed request types
amend approval_requests thêm cột code
backfill APR legacy
deploy code dot-apr-propose / dot-apr-execute đọc cột mới
chạy verification query 0 missing code
rồi mới enact flow P3/P4 ở runtime

Nếu code runtime đọc bảng type trước khi APR legacy/backfill xong, có thể làm pending request cũ không hiển thị hoặc execute fail.

6.4 Thiếu DOT cặp nào?

Có 2 chỗ nên bổ sung:

Cho P2 nên có một DOT A kiểu dot-apr-type-integrity-audit để quét action/request types missing, inactive, orphan reference.
Cho P1/P3 nên có DOT A kiểu dot-ops-code-health hoặc mở rộng dot-dot-health để quét backup/log/test artifact completeness sau mỗi fix_repair_dot.

6.5 Thiếu phân biệt artifact sửa

edit_dot_file hiện đang quá hẹp hoặc quá rộng tùy cách hiểu.

Nếu chỉ cho bash file .sh, migration SQL và wrapper khác bị treo ngoài luật.
Nếu quá rộng, nó đụng cả law docs và config.

Nên định nghĩa rõ phạm vi artifact code vận hành nào được action này chạm tới.

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

P5 — Amend Đ32 schema split: `*_code` + payload JSONB

Mục tiêu: đóng hẳn blocker NT10/NT11/DDL của P2.

Nội dung đề xuất:

Thêm request_type_code TEXT và proposed_action_code TEXT vào approval_requests.
Giữ proposed_action JSONB làm payload chi tiết, không dùng nó làm FK.
FK ON UPDATE CASCADE, ON DELETE RESTRICT.
Legacy row được backfill rồi mới bật constraint cứng/NOT NULL.

P6 — Amend Đ22 scanner policy: annotation + risk-tier

Mục tiêu: giảm false-positive và tránh cấm nhầm mẫu bash hợp lệ.

Nội dung đề xuất:

Thêm marker ngoại lệ bắt buộc có lý do: silent-fail-allow, errexit-allow.
Scanner chấm 3 mức allow / warning / critical.
Chỉ auto-APR cho critical, còn warning thì tạo issue review.

P7 — Amend Đ41 log schema hoặc structured notes cho `ops-code`

Mục tiêu: đóng lỗ hổng text-only ở câu kind='ops-code'.

Nội dung đề xuất:

Hoặc thêm deploy_kind vào vps_deploy_log,
hoặc chuẩn hóa smoke_evidence/notes JSONB để lưu loại deploy, backup artifact, dry-run evidence của ops-code.

P8 — Amend Đ35 verification 3 tầng bắt buộc

Mục tiêu: codify bài học Đ43 rev 2 vào chính flow fix_repair_dot.

Nội dung đề xuất:

Mọi fix DOT canonical phải verify riêng cho:
1. shell semantics,
2. SQL DDL validity,
3. SQL data-path safety.

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

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

Lý do:

Đúng bệnh và đúng hướng: gói amend chẩn đoán rất chính xác 4 lỗ hổng liên hoàn ở Đ41, Đ32, Đ35, Đ22; đặc biệt P3 là flow cần có từ lâu để xử lý DOT canonical enacted bị lỗi mà vẫn giữ NT9.
Rất hợp Hiến pháp: gói này mạnh ở NT4, NT9, NT10, NT12, NT13; không có dấu hiệu vá tạm hay mở bypass tay.
Chưa đủ FINAL vì còn 4 điểm phải sửa inline trước R2:
- (A) P2 phải tách proposed_action_code / request_type_code khỏi payload JSONB; không được FK vào proposed_action hiện hành.
- (B) Phần phụ thuộc phải viết lại cho nhất quán với thứ tự enact P1 → P2 → P3 → P4.
- (C) Retrofit phải tách rõ 14 ngày = silent-fail remediation, 90 ngày = paired-test retrofit.
- (D) §4.1 Đ22 phải thêm annotation + risk-tier scanner để tránh false-positive và false-ban bash hợp lệ.

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

Apply xong P5 + P6 tối thiểu, hoặc đưa các sửa này inline vào P2/P4.
Bổ sung wording xác nhận ON DELETE RESTRICT cho type tables để không khóa cứng lịch sử APR.
Chèn rõ sequencing migration/seed/backfill cho APR legacy trước khi runtime mới đọc bảng type.

Phụ lục ngắn — câu chữ nên sửa ngay trong patch gốc

Ở mục II / P2:
- thay “FK reference từ approval_requests.proposed_action”
- bằng “bổ sung approval_requests.proposed_action_code (TEXT FK) và giữ proposed_action là JSONB payload”.

Ở mục III / phụ thuộc:

viết lại thành:

P1 (Đ41 ops-code layer)    ↓ mở hành lang deploy/log/backupP2 (Đ32 PG-native action/request types)    ↓ mở vocabulary hợp pháp cho APRP3 (Đ35 fix_repair_dot flow)    ↓ tạo cơ chế sửa bug enacted end-to-endP4 (Đ22 silent-fail enforcement)

Ở P4 retrofit clause:
- ghi rõ:
  - “14 ngày” = remediation 13 DOT legacy có silent-fail pattern đã inventory hóa
  - “90 ngày” = paired-test retrofit cho DOT canonical legacy
Ở P4 scan rule:
- thêm annotation marker để tránh cấm nhầm shell pattern hợp lệ.

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

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

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

P1 — Đ41 v1.0 → v1.1: mở rộng ops-code/

P2 — Đ32 v1.0 → v1.1: whitelist chuyển sang PG-native

P3 — Đ35 v5.1 → v5.2: flow fix_repair_dot end-to-end

P4 — Đ22 v1.0 → v1.1: cấm silent-fail pattern

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

NT1 — Làm một lần, dùng mãi

NT2 — Tự động 100%

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

NT4 — Sẵn sàng thay đổi

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

NT6, NT7, NT8

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

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

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

NT12 — DOT theo cặp

NT13 — Ưu tiên PG native

4. Tương tác giữa 4 Patch

Có xung đột không?

Thứ tự enact P1 → P2 → P3 → P4 có hợp lý không?

Atomic transaction khả thi không?

5. Retrofit clause

§6.7 (14 ngày) + §4.2 (90 ngày) đủ bảo vệ legacy không?

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

6.1 Lỗ hổng lớn nhất chưa đóng hẳn

6.2 Edge case gây side-effect ở P4

6.3 Sequencing của seed + migration cho 13 DOT legacy

6.4 Thiếu DOT cặp nào?

6.5 Thiếu phân biệt artifact sửa

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

P5 — Amend Đ32 schema split: *_code + payload JSONB

P6 — Amend Đ22 scanner policy: annotation + risk-tier

P7 — Amend Đ41 log schema hoặc structured notes cho ops-code

P8 — Amend Đ35 verification 3 tầng bắt buộc

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

Phụ lục ngắn — câu chữ nên sửa ngay trong patch gốc

P1 — Đ41 v1.0 → v1.1: mở rộng `ops-code/`

P3 — Đ35 v5.1 → v5.2: flow `fix_repair_dot` end-to-end

Thứ tự enact `P1 → P2 → P3 → P4` có hợp lý không?

P5 — Amend Đ32 schema split: `*_code` + payload JSONB

P7 — Amend Đ41 log schema hoặc structured notes cho `ops-code`