Điều 22 Self-Healing — Amendment DRAFT (non-enacting): preserve detect/list/improve, reframe auto-fix to proposal-only — 2026-06-17
Điều 22 — Self-Healing + Self-Improvement — Amendment DRAFT
DRAFT · NON-ENACTING · READ-ONLY · NON-AUTHORIZING. 2026-06-17, rev1. Law Revision Workstream B1. This is a draft amendment, not an enacted law. It is not adopted, not in force, and does not change
laws/law-22-self-healing.md. It is review material for GPT → Codex → Owner. Codex/GPT PASS ≠ Owner authorization. Engineering PASS / health PASS ≠ authority PASS. Target law: Điều 22 — Luật Tự Sửa Chữa + Tự Cải Tiến v1.2 BAN HÀNH (knowledge/dev/laws/law-22-self-healing.md, rev22). Catalog disposition: Law Merge catalog record #2 = AMEND ("Only law with genuine auto-fix; split detect/list (keep) from auto-fix (re-scope to Owner-gated)") →LAW_READING_INDEX.md§3.3 = READ_NEW_AMENDED_VERSION_PENDING. This document is that pending amended version, in draft form only. Model: F0→F5/FX. In that model the scanner is list-only (FX/D11); mutation flows through the checker (F4) + Owner / Mức 3 / Điều 32 for high-risk.
0. Boundary & non-authorization (read first)
- This draft preserves Điều 22's goal: detect → list → propose → confirm → learn. It only reframes the unsafe rollout mechanism (auto-fix that runs from scanner/health-check output).
- It does not enact, adopt, or put any clause in force. It does not edit, move, or delete
laws/law-22-self-healing.md. It does not patch the Constitution. - It creates no technical design, no Phase-1, no live DB/runtime query, no schema/table/registry/index, no implementation.
- It does not resolve CONS-002/003/004/005, CELL-003/004/007, HOLD-1, HOLD-2, RISK-BYPASS/GC/CAP; it does not change the authority order or the v0.1-stable / FIX7 V3 baseline.
- Default disposition until the Owner acts: HOLD.
1. Preserved goals (what stays — DO NOT weaken)
Điều 22's purpose and its detection/visibility machinery are kept. The amendment changes who acts on a finding and how a mutation is authorized — never the detection, listing, proposal, or learning.
| Preserved from v1.2 | Clause | Status under this draft |
|---|---|---|
| Self-healing loop: NHẬN DIỆN → LIỆT KÊ → … → CẢI TIẾN | §1 | KEEP the loop; reframe step ③ XỬ LÝ (see §3) |
| Detection (DOT scan + realtime trigger/flow finds problems) | §1.1, §4 | KEEP |
Listing / logging to system_issues with category/severity/provenance |
§1.2 | KEEP |
| Proposals (create APR / task when rule not clear) | §1.3 | KEEP (this is already proposal-only) |
| Learning-after-confirmation (repeated pattern → propose architecture/process change) | §1.5, §7.3 | KEEP (proposal, not auto-change) |
| Issue records lifecycle vocabulary (open / resolved) and idempotent matching key (NT1 + Đ14) | §1.1 | KEEP as issue-ledger bookkeeping (see §3 on auto-close) |
| Double-entry accounting (snapshot vs transaction log; mismatch → warn) | §2 | KEEP |
| Three parallel catalogs (system / issues / improvements) | §3 | KEEP |
| "Phơi bày ra ánh sáng" — expose every problem, hide nothing | §4 | KEEP |
Silent-fail ban in ops-code/ + marker exceptions + 3-level scanner + coalesce |
§4.1–§4.1.3 | KEEP (this is detection discipline, not mutation) |
system_health_checks infrastructure ownership (Đ22 owns the table + generic executor) |
§4.3 | KEEP the registry; reframe check_kind='detect_and_fix' (see §3) |
| Two-engine philosophy (DOT = thermometer not medicine; goal = checker IDLE) | §5 | KEEP and strengthen — it already says the checker observes, it does not heal |
| Metrics (detect-before-user; clear-error self-fix rate; pattern → improvement proposal) | §7 | KEEP, but reinterpret metric #2 (see §3) |
The two-engine philosophy in §5 ("DOT kiểm tra = nhiệt kế, không phải thuốc") is the law's own statement that the scanner observes, it does not treat. This amendment makes the rest of the law consistent with §5.
2. Unsafe rollout mechanisms identified (verbatim, with clause)
These are the genuine auto-fix behaviors that run a mutation directly from scanner / health-check output without a checker + Owner gate. They are the reason Điều 22 is AMEND.
| # | Mechanism | Clause | Why unsafe under F0→F5/FX |
|---|---|---|---|
| U1 | Step ③ XỬ LÝ: "tự sửa khi rule rõ" — heal directly when the rule is clear | §1 (3) | Scanner output drives a mutation with no checker/Owner gate. |
| U2 | Case D — AUTO-CLOSE (UPDATE status='resolved'…) and Case C — REOPEN (UPDATE status='open'…reopen_count+1) of system_issues |
§1.1 (5 cases) | Auto-mutation of the issue ledger from scanner output (bookkeeping, but still auto-mutation; task lists auto-close as a target to reframe). |
| U3 | check_kind='detect_and_fix' + auto_fix_action column + the constraint that detect_and_fix rows carry an auto_fix_action |
§4.3 schema | The health-check registry can carry a self-running fix action. |
| U4 | HC-TRIGGER auto_attach_trigger — auto-attach fn_description_birth_guard to governed tables via 7 guards; config hc_trigger_autofix_enabled |
§4.4 | Auto-attaching a trigger is an enforcement/DDL-adjacent mutation run from a scanner finding. |
| U5 | Critical silent-fail pattern → "auto tạo APR fix_repair_dot" |
§4.1.2 | This one is already proposal-only (it creates an APR); keep, but state clearly it proposes, it does not fix. |
| U6 | dot-ops-silent-fail-propose: "không auto-fix toàn diện … trừ mẫu cực chắc chắn" — a carve-out that allows regex auto-rewrite for "very certain" patterns |
§4.2 | The "trừ mẫu cực chắc chắn" exception is a residual auto-mutation path. |
| U7 | Config flags hc_auto_close_enabled (default 'true'), hc_trigger_autofix_enabled |
§1.1, §4.4 | Defaults that enable auto-mutation. |
3. Amendment logic (clause-by-clause reframe)
The single principle: a finding may be detected, listed, and proposed automatically; a mutation may not run from a scanner/health-check finding. Any mutation flows through the checker (F4) and, where high-risk, Owner / Mức 3 / Điều 32. The canonical safe path already exists in the corpus — Điều 35 §6.2 fix_repair_dot: DETECT → PROPOSE (APR) → APPROVE (Điều 32 risk/quorum) → APPLY (backup + dry-run + regression test) → VERIFY (3-tier) → CLOSE. Điều 22 auto-fix should route into that path, not heal from the scanner.
A1 — Step ③ XỬ LÝ becomes proposal-only (reframe U1). Replace "tự sửa khi rule rõ" with: the scanner/loop proposes a fix (APR / task), it does not apply it. "Rule rõ" (clear rule) lowers the risk class of the proposal and may make it eligible for low-risk approval under Điều 32 §4.2 — it does not authorize the scanner to mutate. No mutation is applied from scanner output; mutation runs only after checker + the appropriate Điều 32 gate. Step ④ XÁC NHẬN (re-scan) and step ⑤ CẢI TIẾN (propose architecture/process change) are unchanged — they were already observe/propose.
A2 — Issue-ledger auto-close/reopen scoped to documentary bookkeeping (reframe U2).
Auto-close (case D) and reopen (case C) mutate the issue ledger (system_issues records), not governed/canonical data. Default in the new model: proposal-only, like every other mutation. The narrow exception — retaining auto-close/reopen as pure issue-record bookkeeping — is a separate Owner decision, and if authorized is bounded to: (a) the success gate (NT9 — a "blind" check that errored never auto-closes), (b) source scoped to a system_health_checks.code (scope guard), (c) no downstream mutation of any governed entity, schema, or canonical record, and (d) it closes the record, it never asserts the underlying problem was fixed. Until the Owner decides, treat hc_auto_close_enabled as default off.
A3 — check_kind='detect_and_fix' / auto_fix_action disabled-by-default (reframe U3).
The system_health_checks registry is kept (Đ22 still owns the table + generic executor). But in the new model the executor is list-only: it runs detect_only / verify_only checks and does not execute auto_fix_action. detect_and_fix rows are treated as detect + a proposed fix action — the auto_fix_action becomes the proposed_action payload of an APR, not a self-run command. Any actual fix runs through the checker + Điều 32 gate. (No schema change is performed by this draft; this is a behavior reframe to be realized later under design-before-execution.)
A4 — HC-TRIGGER becomes detect + propose-attach (reframe U4).
HC-TRIGGER may detect governed tables missing trg_desc_guard and propose attaching fn_description_birth_guard (the 7 guards become preconditions of the proposal). It must not auto-attach. Attaching a trigger is an enforcement/DDL-adjacent mutation → it runs only via checker + Owner / Mức 3 / Điều 32 (trigger/DDL changes are not "low-risk"). hc_trigger_autofix_enabled is default off and is not flipped without an Owner decision.
A5 — Keep the proposal paths; close the residual auto-rewrite carve-out (reframe U5, U6).
§4.1.2 (critical → auto-create APR fix_repair_dot) and dot-ops-silent-fail-propose are kept — proposing an APR is allowed. Remove the "trừ mẫu cực chắc chắn" carve-out in §4.2 that permits regex auto-rewrite: there is no auto-rewrite of ops-code/ from a scanner; even "very certain" patterns are proposed, then applied via fix_repair_dot (Điều 35 §6.2) under the Điều 32 gate.
A6 — Config defaults safe (reframe U7).
hc_auto_close_enabled and hc_trigger_autofix_enabled default off in the new model; turning either on is an Owner decision recorded against the relevant gate criteria (mirroring Điều 35 §10's "tiêu chí cứng warn→block" discipline). Engineering/health PASS does not flip these.
A7 — Authority statement (new clause). Add an explicit clause: "Engineering PASS / health PASS ≠ authority PASS. A green scanner, a closed issue, or a passing health check is evidence, not authorization. Only the Owner (or the Điều 32 gate it delegates to) authorizes a mutation; the scanner never does."
4. Proposed amended wording (DRAFT — not enacted)
The following is draft recommended wording for a future, Owner-gated amended Điều 22. It is not enacted and not in force. Final wording is decided later under Owner gate, in
newlaws/.
§1 (reframed) — Vòng lặp Tự phát hiện → Đề xuất → (sau xác nhận) Sửa. "NHẬN DIỆN → LIỆT KÊ → ĐỀ XUẤT → XÁC NHẬN → CẢI TIẾN. Bước XỬ LÝ không tự sửa từ kết quả scanner: scanner/health-check đề xuất (APR/task) — kể cả khi rule rõ. Mọi mutation chạy qua checker (F4) và, nếu high-risk, Owner / Mức 3 / Điều 32, theo flow
fix_repair_dot(Điều 35 §6.2: detect → propose → approve → apply(backup+test) → verify → close). Scanner là list-only (FX/D11)."§1.1 (reframed) — Vòng đời sổ Issue. "open ↔ resolved là bookkeeping của sổ issue, không phải bằng chứng đã sửa gốc. Auto-close (case D) / reopen (case C) mặc định đề-xuất-only; chỉ giữ tự động như bookkeeping sổ issue nếu Owner cho phép riêng, với: success gate (NT9), scope theo
system_health_checks.code, không kéo theo mutation entity/schema/canonical.hc_auto_close_enabledmặc định off."§4.3 (reframed) — Hạ tầng Health Check. "Generic executor là list-only: chạy
detect_only/verify_only, không thực thiauto_fix_action.detect_and_fix= detect + đề xuất (auto_fix_action ⇒ proposed_action của APR). Fix chạy qua checker + Điều 32."§4.4 (reframed) — HC-TRIGGER. "Detect bảng governed thiếu
trg_desc_guard→ đề xuất attachfn_description_birth_guard(7 guard = điều kiện của đề xuất). Không auto-attach. Attach trigger = mutation enforcement/DDL → qua checker + Owner / Mức 3 / Điều 32.hc_trigger_autofix_enabledmặc định off."§4.2 (reframed). "
dot-ops-silent-fail-proposechỉ đề xuất. Bỏ ngoại lệ 'trừ mẫu cực chắc chắn' — không auto-rewriteops-code/từ scanner."§5 (kept, strengthened) + new authority clause. "DOT kiểm tra = nhiệt kế, không phải thuốc. Engineering PASS / health PASS ≠ authority PASS. Scanner xanh / issue đóng / health check pass = bằng chứng, không phải uỷ quyền. Chỉ Owner (hoặc Điều 32 được uỷ quyền) cho phép mutation; scanner thì không."
5. Mapping to F0→F5/FX
| Điều 22 element | F0→F5/FX placement |
|---|---|
| Detection + listing + "phơi bày" | Scanner / Observability (FX · D11) — list-only, no auto-fix, no gate-block |
| Proposal (APR / task) | Routes to Approval (Điều 32) |
| Mutation (fix, trigger attach, schema-adjacent) | Checker (F4) + Owner / Mức 3 / Điều 32 |
fix_repair_dot safe path |
Điều 35 §6.2 — the canonical detect→propose→approve→apply→verify→close lane |
| Learning-after-confirmation | Proposal of architecture/process change; never auto-applied |
This is consistent with the bad-reading the index already rejects: "Scanner can auto-fix because Điều 22 says self-healing — FALSE; the scanner is list-only; Điều 22's genuine auto-fix is exactly why Điều 22 is AMEND" (LAW_READING_INDEX.md §4 #7).
6. Held blockers carried (not resolved here)
- RISK-BYPASS — live
fn_auto_approve_add(160 unvoted applies) at the governance layer contradicts Điều 32 §4 (no self-approve; Cấp B never auto-approved). This amendment reinforces the no-auto-mutate principle but does not close RISK-BYPASS; closing it is Owner/Phase-1 work. - HOLD-2 — atomic promote transaction does not exist; relevant where a "fix" would promote/canonicalize.
- CONS-003 / CELL-003/004/007 — untouched.
- Engineering PASS ≠ authority PASS — restated, not a runtime proof.
7. Bad readings this draft explicitly REJECTS
- "This draft is adopted / Điều 22 is now amended." FALSE — it is a non-enacting draft;
laws/law-22-self-healing.mdis unchanged. - "Auto-fix is still allowed because the law says self-healing." FALSE — auto-fix from scanner output is exactly what is reframed to proposal-only.
- "Detection/listing is being removed." FALSE — detection, listing, proposals, and learning are preserved; only the mutation-from-scanner is reframed.
- "
detect_and_fixchecks may keep running their fix." FALSE — the executor is list-only;auto_fix_actionbecomes a proposed action through checker + Điều 32. - "A green scanner / closed issue authorizes the change." FALSE — engineering/health PASS ≠ authority PASS.
- "This authorizes building the checker, Phase-1, or schema changes." FALSE — no technical design, no Phase-1, no implementation is authorized.
8. Non-authorization checklist
- no adopted amendment: confirmed (DRAFT only) · no rewrite: confirmed · no technical design: confirmed · no Phase-1: confirmed · no DB/runtime query: confirmed · no implementation/schema/table/registry/index: confirmed · no authority-order change: confirmed · no edit/move/delete under
knowledge/dev/laws/: confirmed · no Constitution patch: confirmed · no resolution of CONS/CELL/HOLD/RISK: confirmed · no change to v0.1-stable / FIX7 V3 baseline: confirmed · no v0.2-hardening promotion: confirmed. - Codex/GPT PASS ≠ Owner authorization. Default disposition: HOLD.
Điều 22 amendment DRAFT rev1 | 2026-06-17 | non-enacting | preserve detect/list/improve · reframe auto-fix → proposal-only (checker + Owner/Mức 3/Điều 32) | read-only · non-authorizing