@damphuquy/agent-init 1.4.4 → 2.1.0

package/templates/en/process/context/tests/all-tests.md

@@ -1,56 +1,113 @@
 # Testing Standards & Harness Strategy Context
 
-<testing_context version="1.0">
+<testing_context version="2.0">
 
 <overview>
-  Guidelines for test pyramid calibration, isolation policies, mock conventions, and automated verification harness across the system.
+  Guidelines for test pyramid calibration, isolation policies, mock conventions, fixture hygiene, and automated verification harness across the system.
 </overview>
 
-## 1. Test Pyramid & Classification
+---
+
+## 1. Test Pyramid & Layer Calibration
+
 <test_pyramid>
   <layer name="Unit Tests" path="tests/unit/">
-    - Scope: Pure business logic, domain models, utility functions, edge case branching.
-    - Execution speed: Fast (< 50ms per test), zero network/disk/external I/O.
-    - Mock policy: Mock all I/O boundaries, external clients, and port interfaces.
+    - **Scope:** Pure domain models, business logic calculations, utility functions, edge-case branching.
+    - **Speed & Constraints:** Ultra-fast (< 50ms per test). Zero network calls, zero disk I/O, zero real database connections.
+    - **Mocking Policy:** Mock all port interfaces, external clients, and I/O boundaries.
   </layer>
 
   <layer name="Integration Tests" path="tests/integration/">
-    - Scope: Database persistence, external API client adapters, framework wiring.
-    - Isolation: Ephemeral test containers (e.g. Testcontainers) or dedicated isolated test database per suite.
-    - Teardown: Must guarantee zero state leakage across test runs.
+    - **Scope:** Repository persistence adapters, database queries, migration scripts, HTTP client wrappers, framework wiring.
+    - **Isolation:** Ephemeral test containers (e.g. Testcontainers), in-memory databases, or isolated schema instances per test worker.
+    - **Teardown:** Must guarantee 100% state cleanup with zero leakage across test runs.
   </layer>
 
   <layer name="End-to-End Tests" path="tests/e2e/">
-    - Scope: Critical user journeys, full HTTP/gRPC API lifecycle, regression smoke tests.
-    - Verification: Validates end-to-end contract integrity across subsystems.
+    - **Scope:** Critical user journeys, public API lifecycle, full authentication flows, regression smoke tests.
+    - **Verification:** Validates end-to-end contract integrity across the entire system.
   </layer>
 </test_pyramid>
 
-## 2. Test Harness Policies
-<test_policies>
-  <policy name="Determinism">
-    Zero flaky tests. Tests must not depend on real wall-clock time (use frozen clocks or fake timers) or randomized execution order.
-  </policy>
+---
+
+## 2. Mocking Boundaries & Anti-Patterns
+
+<mocking_boundaries>
+  <rule id="mock_at_architectural_boundary">
+    **Mock at the boundaries, never at the core.** Only mock external infrastructure: third-party HTTP APIs, message brokers, email services, or system clock.
+  </rule>
+
+  <rule id="do_not_mock_domain_or_sut">
+    Never mock the System Under Test (SUT) or pure domain entities/value objects. If a domain entity is hard to instantiate without mocks, its design is coupled and requires refactoring.
+  </rule>
+
+  <rule id="verify_mock_interactions_sparingly">
+    Prefer asserting on return values and observable state changes rather than verifying exact method call counts (`toHaveBeenCalledTimes`), which couples tests to private implementation details.
+  </rule>
+</mocking_boundaries>
+
+---
+
+## 3. Test Fixture & Data Factory Hygiene
+
+<fixture_hygiene>
+  <rule id="data_factories_over_preseeded_db">
+    Use explicit test factories (or builder functions) with sensible defaults rather than relying on brittle, shared SQL seed dumps.
+  </rule>
+
+  <rule id="no_shared_mutable_fixtures">
+    Every test must instantiate its own data fixtures. Never share mutable state or global test variables between tests.
+  </rule>
+
+  <rule id="deterministic_teardown">
+    Always clean up database records, temp files, or mock registries in `afterEach` / `teardown` hooks to prevent cascading cross-test failures.
+  </rule>
+</fixture_hygiene>
+
+---
+
+## 4. Determinism & Flaky Test Zero-Tolerance
+
+<determinism>
+  <rule id="frozen_clock">
+    Never use real wall-clock time (`Date.now()`, `datetime.now()`) in time-sensitive assertions. Use frozen clocks or fake timers to ensure absolute reproducibility.
+  </rule>
+
+  <rule id="order_independence">
+    Tests must pass when run individually or in random order (`--randomize`). Never rely on one test running before another.
+  </rule>
+
+  <rule id="no_arbitrary_sleeps">
+    Never use arbitrary `sleep(1000)` in async tests. Use explicit polling helpers with timeouts (`waitFor`, `eventually`) that resolve as soon as the expected condition is met.
+  </rule>
+</determinism>
+
+---
+
+## 5. Assertion Precision & Failure Clarity
+
+<assertion_precision>
+  <rule id="exact_assertions">
+    Avoid vague assertions (e.g. `expect(res).toBeTruthy()`). Always assert exact expected values, HTTP status codes, and error codes.
+  </rule>
 
-  <policy name="Clean State">
-    Every test must seed its own data or fixtures. Tests must never assume pre-existing database rows.
-  </policy>
+  <rule id="actionable_failure_messages">
+    When custom assertions are used, provide clear error messages indicating what input was given and what specific invariant was violated.
+  </rule>
+</assertion_precision>
 
-  <policy name="Assertion Precision">
-    Avoid vague assertions (e.g. `expect(res).toBeTruthy()`). Always assert exact expected structures, status codes, and error types.
-  </policy>
+---
 
-  <policy name="Fast Feedback">
-    Unit tests must execute in under 30 seconds for the entire suite. Slow integration suites must be cleanly partitioned.
-  </policy>
-</test_policies>
+## 6. Verification Commands Mapping
 
-## 3. Verification Commands Mapping
 <verification_commands>
   <!-- Keep aligned with AGENTS.md <validation_commands> -->
-  <command type="unit">Run fast unit test suite</command>
-  <command type="integration">Run integration/e2e tests</command>
-  <command type="coverage">Run test coverage check</command>
+  <command type="unit">Run fast unit test suite (< 30 seconds total)</command>
+  <command type="integration">Run isolated integration/e2e tests</command>
+  <command type="typecheck">Run static type checker (zero errors, strict mode)</command>
+  <command type="lint">Run linter and format checker (zero warnings)</command>
+  <command type="coverage">Run test coverage report and threshold check</command>
 </verification_commands>
 
 </testing_context>

package/templates/en/process/development-protocols/implementation-standards.md

@@ -1,28 +1,117 @@
 # Implementation & Harness Standards
 
-<implementation_standards version="1.0">
+<implementation_standards version="2.0">
 
 <description>
-  Engineering quality, type safety, and testing conventions for this codebase.
+  Engineering quality, strict typing, clean architecture, and defensive execution conventions. Project-agnostic.
 </description>
 
-## 1. Type Safety & Code Hygiene
-<conventions>
+---
+
+## 1. Type Safety & Static Analysis
+
+<type_safety>
   <rule id="strict_typing">
-    All functions, methods, and class attributes must have explicit type annotations. Use modern union types (`int | None` or `string | null`) and avoid untyped `Any`/`any` unless interfacing with raw external payloads.
+    All functions, methods, and class attributes must have explicit type annotations. Use modern union types (`int | None` or `string | null`). Avoid untyped `Any`/`any` unless deserializing unvalidated external payloads at boundary gateways.
+  </rule>
+
+  <rule id="explicit_return_types">
+    Always declare explicit return types on public functions and methods to enforce compile-time contracts and prevent accidental type widening.
+  </rule>
+
+  <rule id="no_suppression">
+    Never silence linter, formatter, or type-checker errors with inline suppression directives (`# type: ignore`, `eslint-disable`, `@SuppressWarnings`) to artificially pass a validation gate. Fix the underlying root cause.
   </rule>
+</type_safety>
+
+---
+
+## 2. Clean Architecture & Layered Domain Purity
+
+<clean_architecture>
+  <rule id="dependency_rule">
+    Dependencies must only point inward toward the core domain. Inner domain layers must never import or depend on outer infrastructure frameworks, databases, or UI modules.
+  </rule>
+
   <rule id="domain_purity">
-    Code in domain layers must remain pure with zero external infrastructure dependencies.
+    Core business logic, domain entities, and value objects must remain 100% pure with zero side-effects, zero filesystem I/O, and zero network calls.
   </rule>
-  <rule id="immutability">
-    Prefer immutable models for domain events, value objects, and DTOs.
+
+  <rule id="ports_and_adapters">
+    Define abstract interfaces (ports) in the application/domain layer for persistence, external APIs, and messaging. Implement concrete drivers (adapters) strictly within infrastructure packages.
+  </rule>
+
+  <rule id="no_premature_abstraction">
+    Do not introduce speculative abstraction layers, dynamic factories, or unnecessary indirection for simple single-purpose utilities.
+  </rule>
+</clean_architecture>
+
+---
+
+## 3. Error Handling & Fail-Fast Principles
+
+<error_handling>
+  <rule id="fail_fast_at_boundaries">
+    Validate all incoming parameters, payloads, and environment variables at system entrypoints. Reject malformed input immediately before invoking business logic.
+  </rule>
+
+  <rule id="no_silent_swallowing">
+    Never use empty `catch {}`, `except: pass`, or unlogged exception handlers. Every caught exception must either be handled, transformed into a typed domain error, or cleanly propagated.
+  </rule>
+
+  <rule id="typed_domain_errors">
+    Create explicit domain error classes with machine-readable error codes (e.g. `ResourceNotFoundError`, `ValidationError`, `ConcurrencyConflictError`) rather than throwing generic exceptions.
   </rule>
-</conventions>
+</error_handling>
 
-## 2. Test Architecture
-<test_structure>
-  - `tests/unit/`: Fast, isolated tests for domain models, core logic, and mock adapters.
-  - `tests/integration/`: End-to-end flow tests with test services or local databases.
-</test_structure>
+---
+
+## 4. Immutability & Concurrency Safety
+
+<concurrency_and_immutability>
+  <rule id="immutable_data_structures">
+    Prefer immutable models (`dataclass(frozen=True)`, `readonly` interfaces, or `Readonly<T>`) for domain events, configuration objects, and Data Transfer Objects (DTOs).
+  </rule>
+
+  <rule id="no_shared_mutable_state">
+    Avoid global mutable variables, module-level state caches, or singletons with mutable fields. Pass dependencies explicitly via constructors (Dependency Injection).
+  </rule>
+
+  <rule id="safe_async_lifecycle">
+    Always handle asynchronous error rejection and cancellation cleanly. Ensure timeouts are specified for external network calls and database queries.
+  </rule>
+</concurrency_and_immutability>
+
+---
+
+## 5. Observability & Logging Hygiene
+
+<observability_hygiene>
+  <rule id="structured_logging">
+    Use structured logging with key-value context (`task_id`, `user_id`, `component`) instead of unstructured string concatenation.
+  </rule>
+
+  <rule id="no_credential_leakage">
+    Never log sensitive data: passwords, tokens, API keys, cookies, or personally identifiable information (PII).
+  </rule>
+
+  <rule id="clean_production_diff">
+    Remove all temporary debug logs (`console.log`, `print()`, `debugger`, `dump()`) before requesting Gate G3 sign-off.
+  </rule>
+</observability_hygiene>
+
+---
+
+## 6. Defensive Resource Management & Teardown
+
+<resource_management>
+  <rule id="deterministic_teardown">
+    Always manage file handles, network sockets, and database transactions using deterministic scoping constructs (`try...finally`, Python `with`, TypeScript `using`, or language-native RAII).
+  </rule>
+
+  <rule id="isolated_test_state">
+    Test fixtures must create and destroy their own temporary state. Tests must leave the system in a clean state upon completion.
+  </rule>
+</resource_management>
 
 </implementation_standards>

package/templates/en/process/development-protocols/orchestration.md

@@ -1,24 +1,101 @@
 # Subagent Delegation & Orchestration Protocol
 
-<orchestration_protocol version="1.0">
+<orchestration_protocol version="2.0">
 
 <description>
-  Guidelines for delegating, isolating, and coordinating subagents during complex tasks.
+  Engineering guidelines for delegating, isolating, and coordinating subagents during complex, multi-phase tasks. Project-agnostic.
 </description>
 
-## 1. Delegation Principles
-<delegation_rules>
-  <rule id="explicit_scope">
-    Always specify exact files, function signatures, and expected structured output formats.
+---
+
+## 1. Delegation Criteria & Workload Triage
+
+<delegation_criteria>
+  Subagents should be spawned deliberately for bounded, high-leverage subtasks. Do NOT spawn subagents for trivial steps.
+
+  ### When to Delegate to a Subagent:
+  - **Isolated Research Spikes:** Exploring unfamiliar libraries, auditing legacy subsystems, or reading documentation without polluting the parent agent's context window.
+  - **Dedicated Quality Audits:** Independent security vulnerability audits, accessibility reviews (a11y), or strict lint/formatting passes.
+  - **Orthogonal Test Authoring:** Writing standalone unit test fixtures or integration harnesses for a frozen interface contract.
+  - **Parallel Independent Slices:** Implementing non-overlapping, orthogonal components that touch distinct file boundaries.
+
+  ### When Parent Agent MUST Retain Control (Do NOT Delegate):
+  - **Architectural Trade-offs & Decisions:** Authoring `decision.md` options and Gate 1 sign-offs.
+  - **Master Task Contract & Planning:** Defining `task.md`, vertical slice contracts in `plan.md`, and Gate 2 sign-offs.
+  - **Quality Gates & User Approval:** Conducting Gate G3 review sign-off and final `handoff.md` generation.
+  - **Interactive User Clarification:** Any prompt requiring direct user guidance or requirement resolution.
+</delegation_criteria>
+
+---
+
+## 2. Context Containment & Scoping Rules
+
+<context_containment>
+  <rule id="explicit_file_manifest">
+    Always provide the subagent with an explicit list of file paths to inspect or modify. Never prompt a subagent with open-ended instructions like "explore the project" or "look around the codebase".
+  </rule>
+
+  <rule id="port_and_interface_focus">
+    Constrain the subagent's inputs to relevant port interfaces, domain entities, and accompanying test suites. Keep infrastructure noise out of the subagent prompt.
+  </rule>
+
+  <rule id="structured_output_contract">
+    Always demand a structured output format from the subagent (e.g. unified diff, bulleted findings categorized by Confirmed/Observed/Hypothesized, or JSON/markdown table).
+  </rule>
+</context_containment>
+
+---
+
+## 3. Concurrency, Isolation & Write Permissions
+
+<concurrency_and_isolation>
+  <rule id="zero_write_collision">
+    Multiple subagents must NEVER be given write access to the same files or shared mutable database tables concurrently. Overlapping writes cause silent regressions and merge conflicts.
+  </rule>
+
+  <rule id="read_only_by_default">
+    Default subagents to read-only mode whenever possible (e.g. research, code exploration, audit). Only grant write permissions when the target files are strictly isolated to that subagent.
+  </rule>
+
+  <rule id="workspace_isolation">
+    If subagents support isolated workspaces (e.g. branch or worktree mode), use them for speculative spike experiments to ensure the parent working tree remains clean.
+  </rule>
+</concurrency_and_isolation>
+
+---
+
+## 4. State Synchronization & Parent Re-Integration
+
+<state_synchronization>
+  <rule id="parent_owns_master_state">
+    Subagents must NEVER directly edit the parent's master task artifacts (`task.md`, `state.md`, `review.md`). Only the parent agent reconciles subagent outputs into master state files.
+  </rule>
+
+  <rule id="verification_before_acceptance">
+    When a subagent returns modified source code or findings, the parent agent must inspect the diff and execute the slice's designated verifier command before accepting the work.
+  </rule>
+
+  <rule id="evidence_crystallization">
+    Extract verified facts from subagent reports and append them to `state.md > <verification_evidence>`. Discard transient subagent conversation logs to preserve context hygiene.
+  </rule>
+</state_synchronization>
+
+---
+
+## 5. Reactive Coordination, Timeouts & Failure Recovery
+
+<coordination_and_recovery>
+  <rule id="no_polling_loops">
+    Never implement sleep-and-poll loops (`while true; sleep 5; check_status`) to monitor subagents. Rely on the system's reactive message wakeup mechanism to resume execution upon subagent completion.
   </rule>
 
-  <rule id="context_containment">
-    Do not grant unbounded repo access; constrain subagent context to relevant test suites and port contracts.
+  <rule id="retry_budget_enforcement">
+    If a subagent encounters a tool error or recurring failure, enforce the 3-attempt retry budget. If exhausted, record the failure signature in `state.md > <failure_memory>` and escalate to human guidance.
   </rule>
 
-  <rule id="no_polling">
-    Rely on the system's reactive message wakeup mechanism when subagents complete their execution.
+  <rule id="teardown_and_cleanup">
+    Terminate idle or failed subagents cleanly. Ensure any temporary scratch files or experiment branches created by the subagent are deleted before completing the slice.
   </rule>
-</delegation_rules>
+</coordination_and_recovery>
 
 </orchestration_protocol>

package/templates/vi/.agents/behavior.md

@@ -25,9 +25,41 @@ Mọi phản hồi thúc đẩy tiến độ task BẮT BUỘC phải mở đầ
 Chỉ lược bỏ khai báo mode đối với các trao đổi mang tính đàm thoại thuần túy không
 làm thay đổi tiến độ task (ví dụ: giải đáp câu hỏi kỹ thuật, làm rõ phạm vi yêu cầu).
 
+Trong chế độ chạy liên tục (DELEGATED / Fast-Track), Agent mở đầu bằng mode của phase khởi động. Khi hoàn tất một phase và tự động chuyển sang phase tiếp theo trong cùng lượt phản hồi, Agent chèn phân cách chuyển mode rõ ràng:
+`>>> [PHASE TRANSITION: <PHASE_CŨ> -> <PHASE_MỚI>]` và tiếp tục thực thi dưới mode mới ngay lập tức mà không dừng lại.
+
+---
+
+## 2. Chế Độ Làm Việc & Giao Thức Chuyển Giai Đoạn (Working Modes & Transitions)
+
+<working_modes_protocol>
+  Phương thức làm việc được quy định tại thẻ `<working_mode>` trong `task.md` hoặc qua chỉ thị của người dùng trong prompt:
+
+  ### Chế độ PAIR (Mặc định — Hợp tác từng bước):
+  - Agent thực hiện từng phase một.
+  - Khi hoàn thành phase, cập nhật artifact tương ứng và **DỪNG LẠI** để kỹ sư con người kiểm tra, thảo luận và ký duyệt Gate (G1, G2, G3).
+  - Chờ người dùng ra lệnh "Bắt đầu phase tiếp theo" mới chuyển `<current_phase>` trong `task.md` và tiếp tục.
+
+  ### Chế độ DELEGATED (Tự trị / Fast-Track / Skip Permissions):
+  - **Điều kiện kích hoạt:** `<working_mode>DELEGATED</working_mode>` trong `task.md` HOẶC người dùng chỉ thị rõ: "fast-track", "skip permissions", "tự động chạy", "chạy hết các phase", "autonomous".
+  - **Quy tắc vàng:** **TUYỆT ĐỐI KHÔNG DỪNG LẠI GIỮA CÁC PHASE ĐỂ ĐỢI PROMPT "TIẾP THEO".**
+  - **Quy trình tự động chuyển tiếp liên tục:**
+    1. Khi phase hiện tại hoàn thành đủ tiêu chuẩn thoát (exit criteria/checklist), Agent tự động tích chọn `- [x]`.
+    2. Điền thông tin tự động phê duyệt vào artifact: `approved_by: [AUTO: DELEGATED]` kèm ngày giờ và căn cứ kỹ thuật (ở INNOVATE: tự chọn phương án Recommendation tối ưu; ở PLAN: tự khóa hợp đồng phạm vi file).
+    3. Cập nhật ngay `<current_phase>` trong `task.md` sang phase kế tiếp (`RESEARCH` → `INNOVATE` → `PLAN` → `EXECUTE` → `REVIEW`).
+    4. Khởi tạo artifact seed của phase kế tiếp (Copy-On-Demand) và **TIẾP TỤC THỰC THI NGAY LẬP TỨC** trong cùng phiên làm việc.
+  - **Điều kiện dừng duy nhất trong DELEGATED:**
+    - Task đã hoàn thành 100% (Gate 3 PASS, dọn dẹp housekeeping sạch sẽ, tạo `handoff.md`, chuyển sang `completed/`).
+    - HOẶC chạm một trong các Điều Kiện Dừng Khẩn Cấp thực sự (Escalation Triggers trong `guardrails.md`: hết retry budget 3 lần cho cùng 1 lỗi, lệnh phá hủy nguy hiểm, hoặc mâu thuẫn trực tiếp ngoài phạm vi task).
+
+  ### Chế độ MANUAL & DIAGNOSE-ONLY:
+  - `MANUAL`: Người dùng trực tiếp dẫn dắt từng lệnh, Agent chỉ đóng vai trò hỗ trợ cục bộ.
+  - `DIAGNOSE-ONLY`: Chỉ chạy Research & Review để chẩn đoán/kiểm toán lỗi mà không chỉnh sửa mã nguồn.
+</working_modes_protocol>
+
 ---
 
-## 2. Giao Thức Khởi Động Session (Session Startup Protocol)
+## 3. Giao Thức Khởi Động Session (Session Startup Protocol)
 
 Trước khi tiếp tục bất kỳ task đang dang dở nào, nạp lại trạng thái bền vững theo đúng thứ tự sau:
 
@@ -45,7 +77,7 @@ dựa trên các tệp artifact được liệt kê ở trên.
 
 ---
 
-## 3. Quy Tắc Điều Hướng Ngữ Cảnh (Context Navigation Rules)
+## 4. Quy Tắc Điều Hướng Ngữ Cảnh (Context Navigation Rules)
 
 <context_rules>
   <rule id="minimum_context">

package/templates/vi/.agents/guardrails.md

@@ -39,10 +39,11 @@
      chưa được khai báo trong kế hoạch đã duyệt.
   3. Thay đổi cần thiết chạm vào tệp nằm ngoài phạm vi được định nghĩa trong `plan.md`.
   4. Cần một quyết định nghiệp vụ hoặc chính sách chưa có trong `<approved_decisions>`.
+     (Ngoại lệ: Trong chế độ DELEGATED / Fast-Track, Agent được phép tự chọn phương án kỹ thuật được khuyến nghị trong `decision.md` miễn là không vi phạm `<invariants>` hay `<out_of_scope>`).
   5. Cần mở rộng phạm vi ra ngoài mục `<out_of_scope>` trong `task.md`.
 
   Ngoại lệ: KHÔNG dừng nếu thay đổi đã được người dùng ủy quyền rõ ràng
-  trong prompt/spec, hoặc nếu đó là tệp test đi kèm bắt buộc hay cập nhật import.
+  trong prompt/spec (chế độ DELEGATED, fast-track, skip permissions), hoặc nếu đó là tệp test đi kèm bắt buộc hay cập nhật import.
 </escalation_triggers>
 
 ---

package/templates/vi/AGENTS.md

@@ -69,6 +69,12 @@
 
 <riper5_protocol>
 
+  <!-- ─────────────────── CHẾ ĐỘ VẬN HÀNH (WORKING MODES) ─────────────────── -->
+  <working_modes>
+    <mode id="PAIR" default="true">Hợp tác từng bước. Dừng lại sau mỗi phase để kỹ sư kiểm tra và ký duyệt Gate tương ứng.</mode>
+    <mode id="DELEGATED" alias="fast-track,autonomous,skip-permissions">Ủy quyền tự trị. Khi task.md có working_mode=DELEGATED hoặc người dùng chỉ thị fast-track / skip permissions, Agent tự động nghiệm thu các Gate đạt chuẩn ([AUTO: DELEGATED]), tự động chuyển phase trong task.md và thực thi liên tục qua toàn bộ chu trình RIPER-5 mà KHÔNG dừng lại chờ lệnh "tiếp theo".</mode>
+  </working_modes>
+
   <!-- ─────────────────── RÀNG BUỘC TỪNG GIAI ĐOẠN ─────────────────── -->
 
   <phase name="RESEARCH" order="1">
@@ -76,15 +82,16 @@
     <constraint>Không tự ý ra quyết định triển khai.</constraint>
     <constraint>Không tự ý chọn lựa kiến trúc.</constraint>
     <output>Tạo/cập nhật `research.md`. Phân loại bằng chứng thành Đã xác nhận (Confirmed) / Quan sát thấy (Observed) / Giả thuyết (Hypothesized).</output>
-    <gate id="G0">Đánh dấu đạt tất cả Tiêu chí rời khỏi Khảo sát (Research Exit Criteria) trong `research.md` trước khi chuyển tiếp.</gate>
+    <gate id="G0">Đánh dấu đạt tất cả Tiêu chí rời khỏi Khảo sát (Research Exit Criteria) trong `research.md` trước khi chuyển tiếp. Ở chế độ DELEGATED / Fast-Track, Agent tự động đánh giá và chuyển sang INNOVATE ngay lập tức.</gate>
   </phase>
 
   <phase name="INNOVATE" order="2">
     <constraint>CHỈ ĐỌC (READ-ONLY). Không chỉnh sửa mã nguồn.</constraint>
-    <constraint>Đề xuất 2–3 phương án khả thi kèm ma trận đánh đổi (Trade-off). KHÔNG tự ý đơn phương quyết định.</constraint>
-    <constraint>Tuyệt đối không tự ý quyết định Public API / DB schema / chính sách bảo mật / quy tắc nghiệp vụ khi chưa có sự phê duyệt của con người.</constraint>
-    <output>Tạo `decision.md`. Để trống phần `<engineer_decision>` — kỹ sư sẽ điền phần này.</output>
-    <gate id="G1">Gate 1 trong `decision.md` phải được kỹ sư kiểm tra và ký duyệt trước khi chuyển sang Plan.</gate>
+    <constraint>Đề xuất 2–3 phương án khả thi kèm ma trận đánh đổi (Trade-off).</constraint>
+    <constraint>Chế độ PAIR: Để trống phần `<engineer_decision>` — kỹ sư sẽ kiểm tra và điền phần này.</constraint>
+    <constraint>Chế độ DELEGATED / Fast-Track: Tự động chọn phương án khuyến nghị (Recommendation), ghi rõ rationale với `[AUTO: DELEGATED]`, tự ký duyệt Gate 1 và chuyển tiếp ngay sang PLAN.</constraint>
+    <output>Tạo `decision.md`.</output>
+    <gate id="G1">Gate 1 trong `decision.md` được kỹ sư ký duyệt (chế độ PAIR) hoặc tự động ký duyệt bởi Agent với `[AUTO: DELEGATED]` (chế độ DELEGATED / Fast-Track) trước khi chuyển sang Plan.</gate>
   </phase>
 
   <phase name="PLAN" order="3">
@@ -92,7 +99,7 @@
     <constraint>Mỗi lát cắt (slice) phải có công cụ kiểm chứng (verifier), bằng chứng kỳ vọng và điểm hoàn nguyên (rollback point).</constraint>
     <constraint>Hợp đồng phạm vi (danh sách file được phép / cấm sửa) phải tường minh.</constraint>
     <output>Tạo `plan.md`. Điền sẵn các tiêu đề của Ma trận Kiểm chứng (Verification Matrix).</output>
-    <gate id="G2">Gate 2 trong `plan.md` phải được kỹ sư kiểm tra và ký duyệt trước khi chuyển sang Execute.</gate>
+    <gate id="G2">Gate 2 trong `plan.md` được kỹ sư ký duyệt (chế độ PAIR) hoặc tự động ký duyệt bởi Agent với `[AUTO: DELEGATED]` (chế độ DELEGATED / Fast-Track) trước khi chuyển sang Execute.</gate>
   </phase>
 
   <phase name="EXECUTE" order="4">
@@ -100,7 +107,7 @@
     <constraint>Thực hiện từng lát cắt một. Chạy verifier sau mỗi slice. Kiểm tra diff sau mỗi slice.</constraint>
     <constraint>Không refactor lan man. Không sửa các file bị cấm.</constraint>
     <constraint>Cập nhật `state.md` ngay sau mỗi slice hoàn thành.</constraint>
-    <output>Mã nguồn + kiểm thử + cập nhật `state.md` kèm bằng chứng kiểm chứng.</output>
+    <output>Mã nguồn + kiểm thử + cập nhật `state.md` kèm bằng chứng kiểm chứng. Khi hoàn tất toàn bộ lát cắt, tự động chuyển ngay sang REVIEW.</output>
   </phase>
 
   <phase name="REVIEW" order="5">
@@ -108,7 +115,7 @@
     <constraint>Không sửa mã nguồn trong lúc review. Ghi nhận các phát hiện vào `review.md`.</constraint>
     <constraint>Bao quát: hành vi (behavior), kiến trúc (architecture), dữ liệu (data), bảo mật (security), hồi quy (regression).</constraint>
     <output>Tạo `review.md` với các phát hiện được phân loại theo danh mục/mức độ/loại và checklist Gate 3.</output>
-    <gate id="G3">Gate 3 trong `review.md` phải được ký duyệt trước khi bàn giao. Quyết định review phải là PASS.</gate>
+    <gate id="G3">Gate 3 trong `review.md` phải được ký duyệt trước khi bàn giao. Quyết định review phải là PASS. Ở chế độ DELEGATED, Agent tự động kiểm toán toàn diện, tạo `handoff.md`, chuyển task sang `completed/` và báo cáo hoàn thành.</gate>
   </phase>
 
   <!-- Quy tắc hành vi (khai báo mode, retry, escalation, cổng hoàn thành) →

package/templates/vi/process/README.md

@@ -24,6 +24,7 @@ process/
 │   ├── review-template.md.seed       # Artifact giai đoạn Review (Gate 3)
 │   ├── handoff-template.md.seed      # Tóm tắt bàn giao cuối cùng (ngắn gọn)
 │   ├── cancellation-template.md.seed # Biên bản hủy task lưu giữ tri thức
+│   ├── pause-template.md.seed        # Biên bản tạm dừng task & đóng băng an toàn
 │   ├── results-template.tsv.seed     # Bảng theo dõi số liệu benchmark & định lượng
 │   └── program-template.md.seed      # Bản thiết kế chương trình lớn nhiều giai đoạn
 ├── context/                          # Cơ sở tri thức bền vững & router định tuyến
@@ -45,6 +46,7 @@ process/
 │   │       ├── review.md             # Biên bản nghiệm thu kiểm thử
 │   │       ├── handoff.md            # Tóm tắt bàn giao
 │   │       ├── results.tsv           # (Tùy chọn) Theo dõi benchmark & metric
+│   │       ├── paused.md             # (Nếu tạm dừng) Biên bản đóng băng & điều kiện mở lại
 │   │       └── cancelled.md          # (Nếu hủy) Lưu vết nguyên nhân & hoàn nguyên
 │   ├── completed/                    # Lưu trữ các task đã hoàn thành
 │   └── backlog/                      # Ghi chú task tồn đọng: {note_slug}_NOTE_{dd-mm-yy}.md
@@ -69,16 +71,16 @@ flowchart TD
         Task --> Res["research.md"] --> G0{"Gate G0 (Tự động)"}
     end
     subgraph I2["2. INNOVATE (Chỉ đọc)"]
-        G0 --> Dec["decision.md (2-3 Phương án)"] --> G1{"Gate G1 (Kỹ sư duyệt)"}
+        G0 --> Dec["decision.md (2-3 Phương án)"] --> G1{"Gate G1 (Kỹ sư hoặc Auto-DELEGATED)"}
     end
     subgraph P3["3. PLAN (Chỉ lập kế hoạch)"]
-        G1 --> Plan["plan.md (Lát cắt dọc)"] --> G2{"Gate G2 (Kỹ sư ký duyệt)"}
+        G1 --> Plan["plan.md (Lát cắt dọc)"] --> G2{"Gate G2 (Kỹ sư hoặc Auto-DELEGATED)"}
     end
     subgraph E4["4. EXECUTE (Đọc/Ghi theo phạm vi)"]
         G2 --> Code["Thực thi từng Slice"] --> Test["Chạy Verifiers"] --> State["state.md (Bộ nhớ)"]
     end
     subgraph R5["5. REVIEW (Chỉ đọc)"]
-        State --> Rev["review.md (Kiểm toán diff)"] --> G3{"Gate G3 (Kỹ sư duyệt)"}
+        State --> Rev["review.md (Kiểm toán diff)"] --> G3{"Gate G3 (Kỹ sư hoặc Auto-DELEGATED)"}
     end
     subgraph Done["6. HOÀN THÀNH"]
         G3 --> Arch["Chuyển sang completed/"] --> Handoff["handoff.md"]
@@ -88,10 +90,10 @@ flowchart TD
 ```text
 task.md          ← (luôn có) Hợp đồng master, trạng thái RIPER phase/gate, AC, decisions
 research.md      ← (Research) Luồng thực thi, bằng chứng, ranh giới hệ thống
-decision.md      ← (Innovate) Các phương án, bảng đánh đổi, Gate 1 — kỹ sư bắt buộc duyệt
-plan.md          ← (Plan) Các lát cắt, verifiers, hợp đồng phạm vi, Gate 2 — kỹ sư duyệt
+decision.md      ← (Innovate) Các phương án, bảng đánh đổi, Gate 1 (Kỹ sư duyệt hoặc Auto-DELEGATED)
+plan.md          ← (Plan) Các lát cắt, verifiers, hợp đồng phạm vi, Gate 2 (Kỹ sư duyệt hoặc Auto-DELEGATED)
 state.md         ← (Execute) Tiến độ từng slice, bộ nhớ lỗi, ngân sách thử lại
-review.md        ← (Review) Phát hiện kiểm toán, ma trận kiểm chứng, Gate 3
+review.md        ← (Review) Phát hiện kiểm toán, ma trận kiểm chứng, Gate 3 (PASS)
 handoff.md       ← (Complete) Tóm tắt bàn giao ngắn gọn
 ```
 
@@ -107,8 +109,10 @@ handoff.md       ← (Complete) Tóm tắt bàn giao ngắn gọn
 | Thực thi | mã nguồn + kiểm thử + `state.md` |
 | Nghiệm thu | `review.md` |
 | Bàn giao | `handoff.md` |
+| Tạm dừng / Đóng băng | `paused.md` (đóng băng sạch sẽ & checklist mở lại khi bị chặn) |
 | Hủy task | `cancelled.md` (lưu giữ tri thức khi hủy bỏ) |
 | Benchmark / Định lượng | `results.tsv` (theo dõi hiệu năng và số liệu đánh giá) |
+| Chương trình lớn | `program.md` (bản thiết kế chương trình lớn nhiều giai đoạn) |
 | Gate 1 | Phê duyệt trong `decision.md` |
 | Gate 2 | Phê duyệt trong `plan.md` |
 | Gate 3 | Phê duyệt trong `review.md` |
@@ -126,14 +130,14 @@ handoff.md       ← (Complete) Tóm tắt bàn giao ngắn gọn
   </phase>
 
   <phase order="2" name="Innovate">
-    CHỈ ĐỌC. Đề xuất 2–3 phương án kèm ma trận đánh đổi. Không tự ý đơn phương quyết định.
-    Tạo `decision.md`. Kỹ sư phê duyệt Gate 1.
+    CHỈ ĐỌC. Đề xuất 2–3 phương án kèm ma trận đánh đổi.
+    Tạo `decision.md`. Gate 1: Kỹ sư phê duyệt (chế độ PAIR) hoặc Agent tự chọn phương án tối ưu [AUTO: DELEGATED] (chế độ DELEGATED/Fast-Track).
   </phase>
 
   <phase order="3" name="Plan">
     Chỉ tạo/sửa artifact kế hoạch — không sửa mã nguồn.
     Phân rã thành các lát cắt dọc (vertical slices) kèm verifiers, điểm hoàn nguyên và hợp đồng phạm vi.
-    Tạo `plan.md`. Kỹ sư phê duyệt Gate 2.
+    Tạo `plan.md`. Gate 2: Kỹ sư phê duyệt (chế độ PAIR) hoặc Agent tự động khóa hợp đồng lát cắt [AUTO: DELEGATED] (chế độ DELEGATED/Fast-Track).
   </phase>
 
   <phase order="4" name="Execute">
@@ -143,7 +147,7 @@ handoff.md       ← (Complete) Tóm tắt bàn giao ngắn gọn
 
   <phase order="5" name="Review">
     CHỈ ĐỌC. Có thể chạy các lệnh kiểm thử xác minh. Không sửa mã nguồn.
-    Tạo `review.md` kèm các phát hiện. Gate 3 phải PASS trước khi bàn giao.
+    Tạo `review.md` kèm các phát hiện. Gate 3: Phải PASS trước khi bàn giao. Ở chế độ DELEGATED, Agent tự động hoàn tất dọn dẹp housekeeping và tạo `handoff.md`.
   </phase>
 </operational_phases>