ai-developer-skill-os 9.3.1 → 10.1.0

package/.agents/rules/global.md

@@ -1,5 +1,5 @@
 ---
-version: 9.2.0
+version: 10.1.0
 description: "Agent behavior policies applied globally across all capabilities."
 domain: rules
 applies_to: all
@@ -11,7 +11,7 @@ applies_to: all
 
 ---
 
-## R-G-01: Decision Before Action
+## R-G-01: Decision Before Action & Review Loop
 
 **MUST** create a plan before executing any task with complexity ≥ medium.
 
@@ -24,22 +24,31 @@ If medium/high: outline steps first
   ↓
 Execute step by step
   ↓
-Verify each step before next
+Post-Implementation Self-Review (Requirements, Diff & Scope)
+  ↓
+Verify with actual evidence
+  ↓
+Conclude
 ```
 
-**Violation:** Starting to write code before understanding the full scope.
+**Violation:** Starting to write code before understanding the full scope, or claiming completion without self-review.
 
 ---
 
-## R-G-02: Evidence Before Conclusion
+## R-G-02: Evidence Before Conclusion & Causal Chain
 
-**MUST** have concrete evidence before stating a finding or applying a fix.
+**MUST** establish concrete evidence and prove the causal link before stating a finding or applying a fix:
+
+```text
+REQUEST ──► SCOPE ──► TARGETED INSPECTION ──► EVIDENCE ──► ROOT CAUSE ──► MINIMAL FIX ──► VERIFY ──► ANALYZE RESULT ──► STATUS
+```
 
-- Do NOT guess root cause without reading the relevant code.
-- Do NOT assume a bug is fixed without verification.
-- Do NOT report "done" without checking the output.
+- Do NOT jump from Evidence directly to a fix without proving why that evidence points to the root cause.
+- Do NOT guess root cause without inspecting the relevant code.
+- Do NOT assume a bug is fixed without verification evidence.
+- Do NOT report "done" without executing checks and analyzing results.
 
-**Minimum evidence:** File path + line number + quoted code.
+**Minimum evidence:** File path + line number + quoted code + explicit explanation of why it causes the issue.
 
 ---
 
@@ -53,18 +62,17 @@ Verify each step before next
 
 ---
 
-## R-G-04: Token Budget Discipline
+## R-G-04: Token Budget & Retrieval Discipline
 
-**MUST** respect the `token_budget` defined in each skill's frontmatter.
+**MUST** respect the token budget and retrieval efficiency:
 
-- Read files in targeted chunks, never entire large files.
-- Use `grep_search` for pattern discovery, not full-file reads.
-- Stop reading when sufficient evidence is found (`stop_early: true`).
+- Use targeted search tools available in the current environment for pattern discovery.
+- Read only the minimum relevant sections and stop retrieval when sufficient evidence has been established.
 - Never read: `node_modules/`, `dist/`, `.git/`, binary files.
 
 ---
 
-## R-G-05: Retrieval Path (Compact — v9.2)
+## R-G-05: Retrieval Path
 
 When starting a task, follow this sequence:
 
@@ -79,9 +87,8 @@ When starting a task, follow this sequence:
 ```
 
 **Do NOT:**
-- Read `registry/skills-index.yml` to route — use the inline routing table in `.agents/AGENTS.md`
-- Load all skills at once
-- Scan entire repository before starting
+- Load all skills at once.
+- Scan entire repository before starting.
 
 ---
 
@@ -111,7 +118,7 @@ Never silently terminate. Always report exit code and reason.
 
 ## R-G-08: No Silent Errors
 
-**NEVER** use `?.`, `!`, `try/catch {}` (empty catch), or type casting to suppress errors.
+**NEVER** use `!` (non-null assertion), empty `try/catch {}` (suppressing errors silently), or blind type casting (`as any`) to hide errors. Optional chaining (`?.`) is allowed and recommended for safe navigation of nullable/optional properties.
 
 Fix root cause. If root cause is unclear → report as `BLOCKED` with evidence.
 
@@ -130,9 +137,9 @@ Deprecated skills **MUST NOT** be selected. If a user asks for a deprecated skil
 Agent **MUST NOT** execute when selection confidence < threshold.
 
 Agent **SHOULD**:
-1. Ask clarification
-2. Present top 2-3 candidate skills with brief descriptions
-3. Explain what information is missing
+1. Ask clarification.
+2. Present top 2-3 candidate skills with brief descriptions.
+3. Explain what information is missing.
 
 ---
 
@@ -140,11 +147,8 @@ Agent **SHOULD**:
 
 Every SKILL.md `description` field **MUST** satisfy both:
 
-**(a) What it does** — concrete action the skill performs
-**(b) When to use** — trigger context, keywords, situations
-
-**Bad:** `"Xử lý dữ liệu."`
-**Good:** `"Thiết kế và implement API endpoint mới (REST/GraphQL/tRPC). Dùng skill này khi user nhắc đến: viết api, tạo endpoint, thiết kế api, build api, route handler, controller — kể cả khi chỉ hỏi về request/response schema."`
+**(a) What it does** — concrete action the skill performs  
+**(b) When to use** — trigger context, keywords, situations  
 
 Description phải đủ mạnh để AI **không under-trigger** (bỏ qua skill khi lẽ ra nên dùng).
 
@@ -160,3 +164,205 @@ Nếu gần chạm 500 dòng:
 - Layer 1 (frontmatter) luôn trong context
 - Layer 2 (SKILL.md body) nạp khi skill active
 - Layer 3 (references/, scripts/, assets/) nạp on-demand
+
+---
+
+## R-G-13: Laser Focus & Anti-Sprawl
+
+Agent **BẮT BUỘC** khóa chặt phạm vi thực thi theo 3 nguyên tắc thép:
+
+### 13.1. Scope Lock & No Unrelated Changes
+- **Chỉ giải quyết đúng yêu cầu hiện tại:** Không tự mở rộng phạm vi sang refactor, bug fixing, optimization, redesign hoặc cleanup không liên quan.
+- **Cấm sửa lan man:** Không sửa các file không liên quan chỉ vì phát hiện chúng "có thể cải thiện".
+- **Ghi nhận thay vì tự tiện:** Nếu phát hiện vấn đề ngoài phạm vi, **CHỈ GHI NHẬN VÀ BÁO CÁO** trong phần ghi chú, tuyệt đối không tự ý sửa.
+- **Câu hỏi phán xét:** Mọi thay đổi phải trả lời được câu hỏi: *"Thay đổi này có cần thiết trực tiếp cho yêu cầu hiện tại không?"*. Nếu câu trả lời là "KHÔNG" ➔ **TUYỆT ĐỐI KHÔNG THỰC HIỆN**.
+
+### 13.2. File Creation Control (Kiểm Soát Sinh File)
+- **Không tạo file chỉ để làm kiến trúc trông đẹp hơn.**
+- Trước khi tạo file mới, **BẮT BUỘC** kiểm tra repository để xác định:
+  1. Có file/component/service/hook hiện tại nào có thể tái sử dụng được không?
+  2. Có pattern tương tự trong project hay không?
+  3. File mới có thực sự cần thiết cho tính năng hay không?
+- **Ưu tiên chỉnh sửa và tái sử dụng cấu trúc hiện có:** Chỉ tạo file mới khi có lý do kỹ thuật rõ ràng và file đó có trách nhiệm riêng biệt (Single Responsibility). Cấm tạo các abstraction trung gian chỉ để "đúng pattern".
+
+### 13.3. Repository Inspection Rule (Quét Có Mục Đích)
+- Trước khi triển khai, chỉ quét những file và thư mục **có khả năng liên quan trực tiếp**.
+- Tuyệt đối **KHÔNG**:
+  - Quét và phân tích toàn bộ repository một cách không cần thiết.
+  - Đọc hàng loạt file không liên quan.
+  - Biến việc "khảo sát codebase" thành một nhiệm vụ cleanup toàn dự án.
+
+---
+
+## R-G-14: Zero-Faked Pass & Root-Cause Verification
+
+Agent MUST treat **PASS as a verified conclusion, never as a target**.
+
+### 14.1. Root-Cause Gate
+
+Before applying a fix, Agent MUST establish:
+1. What is the observed problem?
+2. Where does it occur?
+3. What code path causes it?
+4. What is the root cause?
+5. Why will the proposed change remove the root cause?
+
+Do NOT apply speculative fixes.
+
+If root cause cannot be established with sufficient evidence:
+```text
+BLOCKED
+Reason: Root cause cannot be established from available evidence.
+```
+
+### 14.2. Minimal Correct Fix
+
+The fix MUST:
+- Address the identified root cause.
+- Be the smallest change that correctly resolves the problem.
+- Preserve unrelated behavior.
+- Avoid introducing unnecessary abstractions or files.
+- Avoid workaround code whose only purpose is to make verification pass.
+
+### 14.3. Post-Implementation Review Gate — REVIEW TRƯỚC KHI PASS
+
+Agent **MUST NOT** declare a task complete immediately after implementation.
+
+Sau khi hoàn thành thay đổi, Agent **BẮT BUỘC** thực hiện một vòng self-review độc lập trước khi chạy verification và kết luận:
+
+```text
+REQUEST ──► PLAN ──► TARGETED INSPECTION ──► EVIDENCE ──► ROOT CAUSE ──► IMPLEMENT
+  │
+  ▼
+🔍 POST-IMPLEMENTATION REVIEW
+  ├── 1. Requirement Review: Đã đáp ứng đúng yêu cầu ban đầu? Có thiếu edge case nào không?
+  ├── 2. Implementation Review: Code có giải quyết triệt để root cause? Có logic/file thừa không?
+  ├── 3. Scope Review (Diff Check): Những file nào đã sửa? Có accidental hay unrelated changes không?
+  ├── 4. Quality Review: Có vi phạm as any, @ts-ignore, silent catch, hay dirty workaround không?
+  └── 5. Verification Review: Đã xác định đúng lệnh test/build thực tế cần chạy chưa?
+  │
+  ├── Nếu Review phát hiện lỗi ──► STOP ──► RE-ANALYZE ──► MINIMAL FIX ──► REVIEW AGAIN
+  │
+  ▼
+14.4. VERIFICATION GATE (Chạy lệnh thực tế) ──► 14.5. FAILURE RE-ANALYSIS (nếu fail)
+  │
+  ▼
+14.6. ANTI-FAKE-PASS ──► 14.7. EVIDENCE-BASED STATUS ──► 14.8. TRUTH-FIRST REPORTING
+```
+
+#### Final Gate Condition:
+Chỉ được kết luận `SUCCESS` khi:
+- Requirement đã được đối chiếu đầy đủ.
+- Implementation đã được self-review độc lập.
+- Scope / Diff đã được kiểm tra (0 unrelated changes).
+- Root cause đã được xử lý đúng.
+- Verification thực tế đạt yêu cầu (có output lệnh thực tế).
+- Không có bất kỳ workaround nào để ép PASS.
+
+> **Implementation complete ≠ Task complete.**  
+> **Task complete = Implementation + Review + Verification + Evidence.**
+
+### 14.4. Verification Gate
+
+After applying the fix and completing self-review, Agent MUST run the most relevant available verification:
+- Unit tests
+- Integration tests
+- Type-check
+- Lint
+- Build
+- Relevant runtime/manual verification
+
+Only verification actually executed may be reported as evidence.
+
+### 14.5. Failure Re-Analysis
+
+If verification FAILS:
+```text
+FAIL
+ ↓
+STOP
+ ↓
+Read actual failure
+ ↓
+Re-analyze root cause
+ ↓
+Determine whether previous diagnosis was incomplete/wrong
+ ↓
+Apply corrected minimal fix
+ ↓
+Review again
+ ↓
+Verify again
+```
+Do NOT repeatedly modify code blindly until the check becomes green.
+
+### 14.6. Anti-Fake-Pass
+
+Agent MUST NOT make a verification pass by:
+- Adding `as any`
+- Adding `@ts-ignore`
+- Adding `@ts-expect-error` to suppress a newly introduced error
+- Disabling lint/type-check/test rules
+- Skipping or deleting failing tests
+- Weakening assertions without justification
+- Hardcoding fake outputs
+- Returning fake/mock data in production code
+- Swallowing exceptions (`catch (e) {}` rỗng)
+- Changing expected results merely to match incorrect behavior
+- Modifying configuration solely to hide failures
+
+### 14.7. Evidence-Based Status
+
+Agent MUST distinguish:
+
+| Status | Requirement |
+|---|---|
+| `SUCCESS` | Correct fix + self-reviewed + relevant verification passed |
+| `BLOCKED` | Root cause/precondition cannot be established or required verification cannot proceed |
+| `FAILED` | Correct execution attempted but task could not be completed |
+| `PARTIAL` | Some scoped work completed, but required verification or implementation remains incomplete |
+
+Never convert `BLOCKED`, `FAILED`, or `PARTIAL` into `SUCCESS` merely because the code was modified.
+
+### 14.8. Truth-First Reporting
+
+Never claim:
+- "100% fixed"
+- "All tests pass"
+- "Build passes"
+- "No issues"
+- "Verified"
+
+unless the corresponding verification was actually executed and passed.
+
+If verification cannot be executed:
+```text
+Status: NOT VERIFIED
+Reason: <concrete reason>
+```
+Do not infer PASS from code inspection alone.
+
+---
+
+## R-G-15: Prompt Interpretation & Control Plane Gate (Risk Gate, Change Budget, Scope Expansion & Evidence Gate)
+
+**MUST** translate raw or concise user requests into an explicit, reviewable **Compiled Execution Prompt**, expose **Prompt Delta**, and enforce 4 control gates before and during execution.
+
+```text
+RAW REQUEST ──► COMPILE & DELTA ──► RISK & BUDGET GATE ──► DECIDE MODE (AUTO/CONFIRM/ASK) ──► EXECUTE ──► SCOPE EXPANSION GATE? ──► EVIDENCE GATE ──► REPORT
+```
+
+### 15.1. Core Maxim
+> `AI MUST NEVER INCREASE THE USER'S INTENDED SCOPE SILENTLY.`  
+> *(The AI may increase implementation detail, but must never silently increase business scope, behavioral scope, architectural scope, security scope, data scope, or change budget).*
+
+### 15.2. Mandatory Gates
+1. **Risk Gate (`Complexity ≠ Risk`):** Đánh giá độc lập Complexity (`L0–L4`) và Risk (`R0–R4`). Nếu `Risk >= R2` hoặc `Complexity >= L3` hoặc đụng đến Auth/DB/Production → BẮT BUỘC chọn chế độ `CONFIRM`.
+2. **Change Budget Gate:** Khóa giới hạn thay đổi (Kỳ vọng 1–3 files, tối đa 5 files; 0 new dependencies; không đổi API/DB trừ khi được yêu cầu).
+3. **Scope Expansion Gate:** Trong khi code, nếu phát hiện phạm vi thực tế vượt Compiled Scope → **STOP EXPANSION NGAY LẬP TỨC**, báo cáo nguyên nhân và recompile để chờ người dùng duyệt (`CONFIRM`).
+4. **Evidence Gate:** `CLAIM LEVEL <= EVIDENCE LEVEL`. Không được khẳng định pass khi chỉ đọc code. Phải phân biệt rõ `VERIFIED`, `PARTIALLY VERIFIED`, và `UNVERIFIED`.
+
+- **Reference:** Detailed policies in [PROMPT_RULES.md](./PROMPT_RULES.md) and [.agents/rules/prompt-compiler.md](.agents/rules/prompt-compiler.md).
+
+
+

package/.agents/rules/prompt-compiler.md

@@ -0,0 +1,170 @@
+---
+version: 11.1.0
+description: "Quy tắc Prompt Compiler v11.1 Control Plane: Cổng kiểm soát hành vi, Risk Gate R0-R4, Change Budget, Scope Expansion Gate, Evidence Gate và Prompt Delta."
+domain: rules
+applies_to: all
+---
+
+# Prompt Compiler Rules v11.1 — Control Plane & Behavioral Gate
+
+> **Câu hỏi domain này trả lời:** *Làm thế nào để kiểm soát hành vi của AI trước và trong khi code, ngăn chặn bành trướng phạm vi âm thầm, giới hạn ngân sách thay đổi và khóa mức độ khẳng định theo bằng chứng thực tế?*
+
+---
+
+## 1. Nguyên Tắc Cốt Lõi & Khẩu Hiệu Kiến Trúc (Core Maxims)
+
+> 1. `AI MUST NEVER INCREASE THE USER'S INTENDED SCOPE SILENTLY.`  
+> *(AI tuyệt đối không bao giờ được âm thầm bành trướng phạm vi ý định của người dùng).*
+> 
+> 2. `The AI may increase implementation detail, but must never silently increase business scope, behavioral scope, architectural scope, security scope, data scope, or change budget.`  
+> *(AI có thể đào sâu chi tiết triển khai kỹ thuật, nhưng cấm âm thầm tăng phạm vi nghiệp vụ, hành vi, kiến trúc, bảo mật, dữ liệu hoặc ngân sách thay đổi).*
+
+---
+
+## 2. Thứ Bậc Ngữ Cảnh Hóa Biên Dịch (Context-Aware Compilation Hierarchy)
+
+```text
+SYSTEM / PLATFORM RULES
+        ↓
+PROJECT RULES
+        ↓
+GLOBAL RULES
+        ↓
+RELEVANT SKILL
+        ↓
+PROJECT CONTEXT / DEV_PROFILE.md
+        ↓
+EXISTING ARCHITECTURE & CODE
+        ↓
+USER REQUIREMENT ◄── [NGUỒN CHÍNH XÁC ĐỊNH MỤC TIÊU CỐT LÕI (WHAT)]
+        ↓
+AI INTERPRETATION
+        ↓
+EXECUTION PLAN   ◄── [QUY CHUẨN KỸ THUẬT & RANH GIỚI BẢO VỆ (HOW & BOUNDARIES)]
+```
+
+- **User Requirement:** Là nguồn sự thật tối thượng để xác định **Mục tiêu cần làm gì (WHAT)**.
+- **Rules, Skills & Codebase:** Đóng vai trò là luật lệ, ranh giới và tiêu chuẩn kỹ thuật để quy định **Cách AI được phép thực hiện an toàn (HOW & BOUNDARIES)**.
+
+---
+
+## 3. Cổng Đánh Giá Rủi Ro Độc Lập (Risk Gate: Complexity ≠ Risk)
+
+Một thay đổi 1 dòng trong file cấu hình Production (`L1`) có thể gây sập hệ thống (`R4`). Hai trục này phải được đánh giá riêng biệt:
+
+### Trục Phức Tạp (Complexity)
+- `L0 — Trivial`: Sửa typo, format markdown.
+- `L1 — Simple`: Sửa 1 hàm nhỏ, tinh chỉnh CSS cục bộ 1 component.
+- `L2 — Normal`: Bug logic thông thường, thêm 1 endpoint/hook trong module.
+- `L3 — Complex`: Tính năng liên tầng (FE + BE), tái cấu trúc module.
+- `L4 — High Architecture`: Thiết kế lại flow hoặc kiến trúc hệ thống.
+
+### Trục Rủi Ro (Risk Levels)
+- `R0 — Safe`: Thao tác chỉ đọc (Read-only), audit, tài liệu.
+- `R1 — Low`: Thay đổi nhỏ, local UI, dễ rollback, không side-effect.
+- `R2 — Medium`: Logic nghiệp vụ, hàm dùng chung, có nguy cơ hồi quy (regression).
+- `R3 — High`: Sửa đổi liên tầng, API contract, database migration, CI/CD config.
+- `R4 — Critical`: Destructive operation (DROP, TRUNCATE, DELETE), bảo mật/auth, production data.
+
+### Ma Trận Quyết Định Chế Độ (Mode Matrix)
+```text
+IF Complexity >= L3                     ──► Minimum CONFIRM
+IF Risk >= R2                           ──► Minimum CONFIRM
+IF Risk >= R3                           ──► CONFIRM + Explicit Risk Report
+IF destructive / auth / production data  ──► BẮT BUỘC CONFIRM (Chờ duyệt [Proceed])
+IF thiếu thông tin / intent mơ hồ        ──► BẮT BUỘC ASK (Hỏi lại, không đoán)
+```
+
+---
+
+## 4. Ngân Sách Thay Đổi (Change Budget Gate)
+
+Khóa chặt quy mô can thiệp cho mỗi task:
+- **Files Budget:** Dự kiến 1–3 files; Tối đa 5 files. Vượt quá 5 files = Vi phạm budget.
+- **Dependencies Budget:** Mặc định = 0 new dependencies. Cấm tự ý `npm install` thêm package nếu chưa hỏi.
+- **API Contract:** Không thay đổi (trừ khi task yêu cầu).
+- **Database Schema:** Không thay đổi (trừ khi task yêu cầu).
+- **Architecture:** Không tự tiện rewrite.
+
+---
+
+## 5. Cổng Chặn Bành Trướng Phạm Vi (Scope Expansion Gate)
+
+Khi đang thực hiện (in-flight execution), nếu AI phát hiện lỗi nằm xuyên tầng hoặc cần sửa ngoài phạm vi đã compile:
+```text
+STOP EXPANSION NGAY LẬP TỨC
+      ↓
+BÁO CÁO PHÁT SINH PHẠM VI (SCOPE EXPANSION REPORT):
+  - Scope ban đầu đã duyệt
+  - Phụ thuộc mới phát hiện
+  - Lý do kỹ thuật vì sao bắt buộc phải mở rộng
+  - Files bị ảnh hưởng & Mức tăng rủi ro (Risk escalation)
+      ↓
+RECOMPILE PROMPT & PROMPT DELTA MỚI
+      ↓
+CHỜ NGƯỜI DÙNG PHÊ DUYỆT (CONFIRM) MỚI ĐƯỢC LÀM TIẾP
+```
+
+---
+
+## 6. Cổng Bằng Chứng Khẳng Định (Evidence Gate)
+
+```text
+NGUYÊN TẮC:
+CLAIM LEVEL <= EVIDENCE LEVEL
+(Mức độ khẳng định của AI không được vượt quá mức độ bằng chứng thực tế thu thập được)
+```
+
+Phân cấp 3 trạng thái nghiệm thu:
+1. **`VERIFIED`:** Đã chạy test/build thực tế trong terminal và PASS.
+2. **`PARTIALLY VERIFIED`:** Static analysis / typecheck / lint PASS, chưa test luồng integration/browser thật.
+3. **`UNVERIFIED`:** Chưa chạy test, chỉ review code tĩnh. **CẤM GHI PASS**, bắt buộc ghi: *"Trạng thái: NOT VERIFIED — Đã sửa logic tĩnh. Cần người dùng kiểm thử thủ công."*
+
+---
+
+## 7. Khung Hiển Thị Mặc Định (Default UI Block với Prompt Delta & Budget)
+
+Khi nhận câu lệnh, AI bắt buộc render cấu trúc sau trước khi code:
+
+````markdown
+## 🧠 1. Tôi hiểu yêu cầu
+[Tóm tắt 1-2 câu về mục tiêu thực sự bạn muốn đạt được]
+
+## 📝 2. Prompt tôi sẽ dùng (Compiled Execution Prompt)
+```text
+Role: <vai trò chuyên trách trong 14 Roles>
+Objective: <mục tiêu đo lường được, định nghĩa rõ "DONE = ?">
+Context: <stack & module liên quan từ DEV_PROFILE.md và codebase>
+Source of Truth: <thứ tự ưu tiên nguồn dữ liệu>
+Scope:
+  - IN-SCOPE: <file/hàm được phép sửa>
+  - OUT-OF-SCOPE: <vùng cấm tuyệt đối>
+Constraints: Minimal Safe Change, YAGNI, không phá vỡ API/DB hiện có, zero fake pass
+Process: <các bước logic tối giản>
+Acceptance Criteria:
+  - [ ] <Điều kiện kiểm chứng 1>
+  - [ ] <Điều kiện kiểm chứng 2>
+```
+
+## 🔍 3. Prompt Delta (Tôi đã diễn giải thêm)
+
+### User đã yêu cầu:
+- [Nguyên văn câu lệnh bạn đưa]
+
+### AI suy luận từ context:
+- [Những điểm kỹ thuật AI bổ sung dựa trên mã nguồn thực tế]
+
+### AI KHÔNG tự giả định:
+- [Những ranh giới AI tự khóa lại: không rewrite, không đổi DB, không sửa lan man]
+
+## 📊 4. Đánh Giá Rủi Ro & Ngân Sách Thay Đổi (Risk & Budget)
+- **Độ phức tạp / Rủi ro:** `L[0-4]` / `R[0-4]` — [Đánh giá ngắn]
+- **Ngân sách file (Change Budget):** Tối đa [N] files (`path/to/file1`)
+- **Dependencies mới:** 0 package
+
+## 📋 5. Các bước thực hiện
+1. [Khảo sát] → 2. [Thực thi tối thiểu] → 3. [Xác minh theo Evidence Gate]
+
+## ⚡ 6. Execution Mode
+**[ AUTO | CONFIRM | ASK ]** — [Lý do lựa chọn mode dựa trên ma trận Risk & Complexity]
+````