YÊU CẦU GÓP Ý — Điều 30: Luật Bảo vệ Hồi quy (Regression Protection Law)

Ngày: 2026-03-22 | Gửi: Hội đồng AI (GPT, Gemini, Claude) Tài liệu cần đọc TRƯỚC khi góp ý:

1. search_knowledge("regression protection law") — Điều 30 Draft v1.0
2. search_knowledge("hiến pháp kiến trúc") — Hiến pháp v3.6, đặc biệt Điều 1 (5 Luật Bất biến), Điều 22 (Tự sửa chữa)
3. search_knowledge("design feasibility formula") — 4 yếu tố khả thi
4. search_knowledge("operating rules SSOT") — OR v4.58, §0-T + §0-S

---

BỐI CẢNH

Vấn đề: S160 — Agent hoàn thành Phase A-D (PG backend OK: 33 species, 138/138 mapping, 15,307 birth records, fn_registry_health() 138/138 KHỚP). PR #565 deploy cho UI changes (cột "Thành phần" + 33 species matrix). Agent báo cáo "PASS, verified" dựa trên API response + SSR chunk check.

Thực tế: Orchestrator verify trực tiếp trên browser → phát hiện PR #565 GÂY REGRESSION NGHIÊM TRỌNG:

• Dòng 7-10 (Phân loại loài, Mồ côi, Phantom, Không quản trị) BIẾN MẤT
• Cột delta +/- BỊ XÓA
• Cột "Thành phần" KHÔNG HIỆN (dù claim deployed)
• Species Matrix link MẤT

Nguyên nhân gốc: Agent verify bằng API/SSR chunk, không verify bằng mắt trên browser. Luật/quy tắc/checkpoint = phụ thuộc agent nhớ + tuân thủ → KHÔNG scale. Quy mô hiện tại < 1‰ production mà đã loạn.

Giải pháp đề xuất: Điều 30 — Playwright E2E Tests trong CI pipeline. Máy kiểm tra máy. PR phá hỏng = test FAIL = KHÔNG merge được.

---

CÂU HỎI CHO HỘI ĐỒNG

1. Thiết kế tổng thể

• 3 tầng bảo vệ (Playwright CI → Smoke test → Visual verify) có đủ không? Cần thêm tầng nào?
• Playwright là lựa chọn đúng? Có framework nào phù hợp hơn cho stack Nuxt + Directus?

2. Quy trình 3 mũ

• Nâng từ 2 mũ → 3 mũ (thêm verify visual): hợp lý? Quá nặng? Có cách nào tích hợp mũ 3 vào tự động?
• Nếu Playwright tests cover đủ → mũ 3 (verify visual) có còn cần không?

3. Scale

• 20 trang hiện tại → 200 trang → 2000 trang: CI time tăng thế nào? Giải pháp sharding/parallel đủ không?
• E2E tests chạy trên production URL vs staging: trade-off gì? Nên chọn gì cho Incomex?

4. Quan hệ với Điều 22 (Tự sửa chữa)

• Điều 30 = phòng ngừa (chặn regression trước merge). Điều 22 = phát hiện (tự tìm lỗi sau deploy). Hai điều bổ sung nhau đúng không? Có overlap không cần?

5. Visual Snapshot (BackstopJS)

• Tầng 3 (visual snapshot) = TD-340, triển khai sau. Có nên đưa vào Điều 30 luôn hay tách riêng?

6. Khả năng thực thi

• Incomex hiện có GH Actions runner miễn phí. Playwright cài thêm ~300MB. CI time +2-5 phút per PR. Chi phí chấp nhận được?
• Agent viết E2E tests = thêm công sức. Nhưng viết 1 lần dùng mãi. Trade-off hợp lý?

7. Cải tiến luật

• Luật có điểm nào mơ hồ, thiếu, hoặc quá cứng?
• Có best practice nào từ ngành IT mà luật chưa cover?

---

FORMAT GÓP Ý

Mỗi reviewer trả lời:

## [Tên reviewer: GPT / Gemini / Claude]

### Đánh giá tổng thể: [ĐỒNG Ý / ĐỒNG Ý CÓ SỬA / PHẢN ĐỐI]

### Điểm mạnh:
- ...

### Cần sửa / bổ sung:
- ...

### Trả lời câu hỏi:
1. ...
2. ...

### Đề xuất thêm:
- ...

---

Review request Điều 30 | 2026-03-22 | Chờ hội đồng 3 AI