@damphuquy/agent-init 1.4.3 → 2.0.0

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

@@ -1,56 +1,113 @@
 # Tiêu Chuẩn Kiểm Thử & Chiến Lược Khung Thử Nghiệm (Testing Context)
 
-<testing_context version="1.0">
+<testing_context version="2.0">
 
 <overview>
-  Hướng dẫn hiệu chỉnh kim tự tháp kiểm thử, chính sách cách ly, quy ước mock và khung kiểm tra tự động xuyên suốt hệ thống.
+  Hướng dẫn hiệu chỉnh kim tự tháp kiểm thử, chính sách cách ly, quy ước mock, vệ sinh fixture dữ liệu và khung kiểm tra tự động xuyên suốt hệ thống.
 </overview>
 
-## 1. Kim Tự Tháp Kiểm Thử & Phân Loại (Test Pyramid & Classification)
+---
+
+## 1. Kim Tự Tháp Kiểm Thử & Phân Loại Tầng (Test Pyramid & Classification)
+
 <test_pyramid>
   <layer name="Unit Tests (Kiểm thử đơn vị)" path="tests/unit/">
-    - Phạm vi: Logic nghiệp vụ thuần túy, domain models, hàm tiện ích, phân nhánh trường hợp biên.
-    - Tốc độ thực thi: Rất nhanh (< 50ms mỗi test), không có I/O mạng / đĩa / ngoại vi.
-    - Chính sách mock: Mock toàn bộ ranh giới I/O, client bên ngoài và giao diện cổng (port interfaces).
+    - **Phạm vi:** Logic nghiệp vụ thuần túy, mô hình domain, hàm tiện ích, rẽ nhánh trường hợp biên.
+    - **Tốc độ & Ràng buộc:** Cực nhanh (< 50ms mỗi test). Không gọi mạng, không đọc/ghi đĩa I/O, không kết nối database thật.
+    - **Chính sách Mock:** Mock toàn bộ giao diện cổng (port interfaces), client ngoại vi và ranh giới I/O.
   </layer>
 
   <layer name="Integration Tests (Kiểm thử tích hợp)" path="tests/integration/">
-    - Phạm vi: Lưu trữ cơ sở dữ liệu, adapter gọi API bên ngoài, cấu hình framework.
-    - Mức độ cách ly: Test containers tạm thời (ví dụ: Testcontainers) hoặc database test cách ly riêng cho từng suite.
-    - Dọn dẹp (Teardown): Phải đảm bảo không rò rỉ dữ liệu hoặc trạng thái giữa các lần chạy test.
+    - **Phạm vi:** Adapter lưu trữ repository, truy vấn cơ sở dữ liệu, file migration, wrapper gọi HTTP client, cấu hình framework.
+    - **Cách ly:** Test containers tạm thời (ví dụ: Testcontainers), in-memory database, hoặc schema cách ly riêng cho mỗi worker chạy test.
+    - **Dọn dẹp (Teardown):** Bắt buộc phải đảm bảo dọn dẹp dữ liệu 100%, không để rò rỉ trạng thái giữa các lần chạy.
   </layer>
 
   <layer name="End-to-End Tests (Kiểm thử đầu-cuối)" path="tests/e2e/">
-    - Phạm vi: Các luồng trải nghiệm người dùng trọng yếu, toàn bộ vòng đời HTTP/gRPC API, regression smoke tests.
-    - Kiểm chứng: Xác thực tính toàn vẹn hợp đồng đầu-cuối xuyên suốt các subsystem.
+    - **Phạm vi:** Các luồng trải nghiệm người dùng trọng yếu, toàn bộ vòng đời API công khai, luồng xác thực auth hoàn chỉnh, regression smoke tests.
+    - **Kiểm chứng:** Xác thực tính toàn vẹn hợp đồng đầu-cuối xuyên suốt toàn bộ hệ thống.
   </layer>
 </test_pyramid>
 
-## 2. Chính Sách Khung Kiểm Thử (Test Harness Policies)
-<test_policies>
-  <policy name="Determinism (Tính tiền định)">
-    Tuyệt đối không có test chập chờn (flaky tests). Test không được phụ thuộc vào thời gian thực tế của đồng hồ hệ thống (sử dụng frozen clock hoặc fake timer) hay thứ tự thực thi ngẫu nhiên.
-  </policy>
+---
+
+## 2. Ranh Giới Mocking & Các Phản Mẫu (Mocking Boundaries)
+
+<mocking_boundaries>
+  <rule id="mock_at_architectural_boundary">
+    **Mock tại ranh giới kiến trúc, không bao giờ mock ở lõi.** Chỉ mock hạ tầng bên ngoài: HTTP API bên thứ ba, message broker, dịch vụ email, hoặc đồng hồ hệ thống.
+  </rule>
+
+  <rule id="do_not_mock_domain_or_sut">
+    Tuyệt đối không mock Hệ thống đang được kiểm thử (System Under Test - SUT) hoặc các thực thể domain / value objects thuần túy. Nếu một thực thể domain khó khởi tạo nếu thiếu mock, thiết kế đó đang bị thắt chặt và cần được tái cấu trúc (refactor).
+  </rule>
+
+  <rule id="verify_mock_interactions_sparingly">
+    Ưu tiên khẳng định dựa trên giá trị trả về và thay đổi trạng thái quan sát được hơn là kiểm tra số lần gọi hàm nội bộ (`toHaveBeenCalledTimes`), tránh việc gắn chặt test vào chi tiết triển khai ngầm.
+  </rule>
+</mocking_boundaries>
+
+---
+
+## 3. Vệ Sinh Fixture Kiểm Thử & Data Factory (Fixture Hygiene)
+
+<fixture_hygiene>
+  <rule id="data_factories_over_preseeded_db">
+    Sử dụng test factories (hoặc builder functions) rõ ràng với giá trị mặc định hợp lý thay vì phụ thuộc vào các file dump SQL seed tĩnh dùng chung dễ vỡ.
+  </rule>
+
+  <rule id="no_shared_mutable_fixtures">
+    Mỗi bài test bắt buộc phải tự khởi tạo dữ liệu của riêng mình. Tuyệt đối không chia sẻ trạng thái biến đổi hoặc biến test toàn cục giữa các bài test.
+  </rule>
+
+  <rule id="deterministic_teardown">
+    Luôn dọn sạch bản ghi database, tệp tạm thời hoặc đăng ký mock trong các hook `afterEach` / `teardown` để ngăn chặn lỗi dây chuyền sang các bài test khác.
+  </rule>
+</fixture_hygiene>
+
+---
+
+## 4. Tính Tiền Định & Không Chấp Nhận Test Chập Chờn (Determinism)
+
+<determinism>
+  <rule id="frozen_clock">
+    Tuyệt đối không sử dụng đồng hồ thực tế của hệ thống (`Date.now()`, `datetime.now()`) trong các khẳng định nhạy cảm về thời gian. Sử dụng frozen clock hoặc fake timer để đảm bảo kết quả tái lập tuyệt đối.
+  </rule>
+
+  <rule id="order_independence">
+    Các bài test bắt buộc phải chạy pass khi chạy riêng lẻ hoặc chạy theo thứ tự ngẫu nhiên (`--randomize`). Không bao giờ phụ thuộc vào việc bài test này phải chạy trước bài test kia.
+  </rule>
+
+  <rule id="no_arbitrary_sleeps">
+    Tuyệt đối không dùng lệnh chờ tùy tiện `sleep(1000)` trong test bất đồng bộ. Sử dụng helper kiểm tra định kỳ có timeout (`waitFor`, `eventually`) để hoàn thành ngay khi điều kiện kỳ vọng được thỏa mãn.
+  </rule>
+</determinism>
+
+---
+
+## 5. Độ Chính Xác Của Khẳng Định (Assertion Precision)
+
+<assertion_precision>
+  <rule id="exact_assertions">
+    Tránh các khẳng định mơ hồ (ví dụ: `expect(res).toBeTruthy()`). Luôn khẳng định cấu trúc giá trị chính xác, mã trạng thái HTTP và mã lỗi cụ thể.
+  </rule>
 
-  <policy name="Clean State (Trạng thái sạch)">
-    Mỗi bài test phải tự khởi tạo dữ liệu seed hoặc fixtures riêng của mình. Không bao giờ giả định sẵn có các dòng dữ liệu trong database.
-  </policy>
+  <rule id="actionable_failure_messages">
+    Khi viết assertion tùy biến, cung cấp thông báo lỗi rõ ràng chỉ ra dữ liệu đầu vào là gì và điều kiện bất biến nào đã bị vi phạm.
+  </rule>
+</assertion_precision>
 
-  <policy name="Assertion Precision (Độ chính xác của khẳng định)">
-    Tránh các khẳng định mơ hồ (ví dụ: `expect(res).toBeTruthy()`). Luôn khẳng định cấu trúc chính xác kỳ vọng, mã trạng thái HTTP (status code) và loại lỗi.
-  </policy>
+---
 
-  <policy name="Fast Feedback (Phản hồi nhanh)">
-    Toàn bộ bộ unit test phải hoàn thành trong vòng dưới 30 giây. Các bộ integration test chậm phải được phân vùng rõ ràng.
-  </policy>
-</test_policies>
+## 6. Ánh Xạ Lệnh Kiểm Tra (Verification Commands Mapping)
 
-## 3. Ánh Xạ Lệnh Kiểm Tra (Verification Commands Mapping)
 <verification_commands>
   <!-- Giữ đồng bộ với <validation_commands> trong AGENTS.md -->
-  <command type="unit">Chạy bộ kiểm thử unit test nhanh</command>
-  <command type="integration">Chạy kiểm thử tích hợp integration/e2e</command>
-  <command type="coverage">Chạy kiểm tra độ bao phủ test coverage</command>
+  <command type="unit">Chạy bộ kiểm thử unit test nhanh (< 30 giây toàn bộ)</command>
+  <command type="integration">Chạy kiểm thử tích hợp integration/e2e cách ly</command>
+  <command type="typecheck">Chạy kiểm tra kiểu tĩnh (0 lỗi, strict mode)</command>
+  <command type="lint">Chạy linter và kiểm tra format (0 cảnh báo)</command>
+  <command type="coverage">Chạy báo cáo độ bao phủ test coverage và ngưỡng tối thiểu</command>
 </verification_commands>
 
 </testing_context>

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

@@ -1,28 +1,117 @@
-# Tiêu Chuẩn Triển Khai & Khung Kiểm Thử (Implementation Standards)
+# Tiêu Chuẩn Triển Khai & Khung Kỹ Thuật (Implementation Standards)
 
-<implementation_standards version="1.0">
+<implementation_standards version="2.0">
 
 <description>
-  Quy chuẩn chất lượng kỹ thuật, an toàn kiểu dữ liệu (type safety) và kiểm thử cho codebase này.
+  Quy chuẩn chất lượng kỹ thuật, an toàn kiểu dữ liệu, kiến trúc sạch và thực thi phòng thủ cho codebase. Dùng chung cho mọi dự án.
 </description>
 
-## 1. An Toàn Kiểu Dữ Liệu & Vệ Sinh Code (Type Safety & Code Hygiene)
-<conventions>
+---
+
+## 1. An Toàn Kiểu Dữ Liệu & Phân Tích Tĩnh (Type Safety & Static Analysis)
+
+<type_safety>
   <rule id="strict_typing">
-    Toàn bộ các hàm, phương thức và thuộc tính class bắt buộc phải có chú thích kiểu dữ liệu (type annotations) rõ ràng. Sử dụng union types hiện đại (`int | None` hoặc `string | null`) và tránh dùng `Any`/`any` không định kiểu trừ khi giao tiếp với payload bên ngoài thô.
+    Toàn bộ các hàm, phương thức và thuộc tính class bắt buộc phải có chú thích kiểu dữ liệu (type annotations) rõ ràng. Sử dụng union types hiện đại (`int | None` hoặc `string | null`). Tránh dùng `Any`/`any` không định kiểu trừ khi giải mã dữ liệu đầu vào thô chưa xác thực tại cổng biên.
+  </rule>
+
+  <rule id="explicit_return_types">
+    Luôn khai báo kiểu trả về tường minh cho các hàm và phương thức public để áp đặt hợp đồng lúc biên dịch (compile-time) và ngăn ngừa hiện tượng suy luận kiểu bị mở rộng vô ý.
+  </rule>
+
+  <rule id="no_suppression">
+    Tuyệt đối không tắt lỗi linter, formatter hoặc type-checker bằng comment bỏ qua nội dòng (`# type: ignore`, `eslint-disable`, `@SuppressWarnings`) để vượt qua cổng kiểm tra giả tạo. Phải xử lý triệt để nguyên nhân gốc rễ.
   </rule>
+</type_safety>
+
+---
+
+## 2. Kiến Trúc Sạch & Độ Thuần Khiết Domain (Clean Architecture & Domain Purity)
+
+<clean_architecture>
+  <rule id="dependency_rule">
+    Chiều phụ thuộc (dependency) chỉ được phép hướng vào lõi Domain bên trong. Các tầng domain bên trong tuyệt đối không import hay phụ thuộc vào framework hạ tầng, database hoặc UI bên ngoài.
+  </rule>
+
   <rule id="domain_purity">
-    Mã nguồn trong các tầng domain phải thuần khiết với 0 phụ thuộc vào hạ tầng bên ngoài (zero external infrastructure dependencies).
+    Logic nghiệp vụ cốt lõi, thực thể domain và value objects phải thuần khiết 100% với 0 tác dụng phụ (zero side-effects), không thực hiện I/O tệp hệ thống và không gọi mạng.
   </rule>
-  <rule id="immutability">
-    Ưu tiên các mô hình bất biến (immutable models) cho các sự kiện domain (domain events), value objects và DTOs.
+
+  <rule id="ports_and_adapters">
+    Định nghĩa giao diện trừu tượng (ports) trong tầng application/domain cho lưu trữ dữ liệu, API bên ngoài và nhắn tin. Triển khai các driver cụ thể (adapters) độc quyền trong các package hạ tầng (infrastructure).
+  </rule>
+
+  <rule id="no_premature_abstraction">
+    Không tự ý đưa vào các lớp trừu tượng mang tính suy diễn, dynamic factory hoặc lớp trung gian bắc cầu không cần thiết cho các tiện ích đơn chức năng đơn giản.
+  </rule>
+</clean_architecture>
+
+---
+
+## 3. Xử Lý Lỗi & Nguyên Tắc Thất Bại Sớm (Error Handling & Fail-Fast)
+
+<error_handling>
+  <rule id="fail_fast_at_boundaries">
+    Kiểm tra hợp lệ toàn bộ tham số, payload và biến môi trường ngay tại điểm vào của hệ thống. Từ chối dữ liệu sai lệch ngay lập tức trước khi gọi vào logic nghiệp vụ.
+  </rule>
+
+  <rule id="no_silent_swallowing">
+    Tuyệt đối không sử dụng `catch {}` rỗng, `except: pass` hoặc bắt ngoại lệ mà không ghi log. Mọi ngoại lệ bị bắt phải được xử lý, chuyển đổi thành lỗi domain có định kiểu hoặc lan truyền (propagate) sạch sẽ.
+  </rule>
+
+  <rule id="typed_domain_errors">
+    Tạo các class lỗi domain rõ ràng kèm mã lỗi đọc được bằng máy (ví dụ: `ResourceNotFoundError`, `ValidationError`, `ConcurrencyConflictError`) thay vì ném ra các exception chung chung.
   </rule>
-</conventions>
+</error_handling>
 
-## 2. Kiến Trúc Kiểm Thử (Test Architecture)
-<test_structure>
-  - `tests/unit/`: Các bài test nhanh, cách ly cho domain models, logic cốt lõi và mock adapters.
-  - `tests/integration/`: Các bài test luồng đầu-cuối với dịch vụ kiểm thử hoặc database nội bộ.
-</test_structure>
+---
+
+## 4. Bất Biến & An Toàn Khi Chạy Đồng Thời (Immutability & Concurrency Safety)
+
+<concurrency_and_immutability>
+  <rule id="immutable_data_structures">
+    Ưu tiên các cấu trúc dữ liệu bất biến (`dataclass(frozen=True)`, `readonly` interface, hoặc `Readonly<T>`) cho các sự kiện domain, cấu hình và DTO.
+  </rule>
+
+  <rule id="no_shared_mutable_state">
+    Tránh sử dụng biến toàn cục có thể thay đổi (mutable globals), cache trạng thái cấp module hoặc singleton có trường biến đổi. Truyền dependency rõ ràng thông qua hàm khởi tạo (Dependency Injection).
+  </rule>
+
+  <rule id="safe_async_lifecycle">
+    Luôn xử lý dọn dẹp và từ chối lỗi bất đồng bộ (async error rejection/cancellation) cẩn thận. Thiết lập timeout rõ ràng cho mọi lệnh gọi mạng hoặc truy vấn cơ sở dữ liệu.
+  </rule>
+</concurrency_and_immutability>
+
+---
+
+## 5. Giám Sát & Vệ Sinh Ghi Log (Observability & Logging Hygiene)
+
+<observability_hygiene>
+  <rule id="structured_logging">
+    Sử dụng ghi log có cấu trúc (structured logging) kèm ngữ cảnh dạng key-value (`task_id`, `user_id`, `component`) thay vì nối chuỗi văn bản thuần túy.
+  </rule>
+
+  <rule id="no_credential_leakage">
+    Không bao giờ ghi log dữ liệu nhạy cảm: mật khẩu, tokens, API keys, cookies hoặc thông tin nhận dạng cá nhân (PII).
+  </rule>
+
+  <rule id="clean_production_diff">
+    Xóa sạch toàn bộ debug log tạm thời (`console.log`, `print()`, `debugger`, `dump()`) trước khi đề nghị ký duyệt Gate G3.
+  </rule>
+</observability_hygiene>
+
+---
+
+## 6. Quản Lý Tài Nguyên Phòng Thủ & Dọn Dẹp (Resource Management & Teardown)
+
+<resource_management>
+  <rule id="deterministic_teardown">
+    Luôn quản lý con trỏ tệp (file handles), kết nối mạng socket và transaction database bằng các cấu trúc giải phóng tiền định (`try...finally`, Python `with`, TypeScript `using`, hoặc RAII nguyên bản của ngôn ngữ).
+  </rule>
+
+  <rule id="isolated_test_state">
+    Mỗi fixture kiểm thử phải tự tạo và tự dọn sạch trạng thái tạm thời của mình. Không để sót lại dữ liệu rác sau khi chạy xong test.
+  </rule>
+</resource_management>
 
 </implementation_standards>

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

@@ -1,24 +1,101 @@
-# Giao Thức Phân Công & Điều Phối Subagent (Orchestration Protocol)
+# Giao Thức Phân Công & Điều Phối Subagent (Subagent Orchestration Protocol)
 
-<orchestration_protocol version="1.0">
+<orchestration_protocol version="2.0">
 
 <description>
-  Hướng dẫn phân công nhiệm vụ, cách ly và phối hợp subagent trong các task phức tạp.
+  Hướng dẫn kỹ thuật phân công nhiệm vụ, cô lập phạm vi và phối hợp subagent trong các tác vụ phức tạp nhiều giai đoạn. Dùng chung cho mọi dự án.
 </description>
 
-## 1. Nguyên Tắc Phân Công (Delegation Principles)
-<delegation_rules>
-  <rule id="explicit_scope">
-    Luôn chỉ định danh sách file chính xác, chữ ký hàm (function signatures) và định dạng đầu ra có cấu trúc kỳ vọng.
+---
+
+## 1. Tiêu Chí Phân Công & Phân Luồng Tác Vụ (Delegation Criteria)
+
+<delegation_criteria>
+  Subagent chỉ nên được khởi tạo có chủ đích cho các tác vụ con có ranh giới rõ ràng, đòn bẩy cao. TUYỆT ĐỐI KHÔNG khởi tạo subagent cho các bước thực thi nhỏ nhặt, tầm thường.
+
+  ### Khi nào NÊN ủy quyền cho Subagent:
+  - **Khảo sát chuyên sâu độc lập (Research Spikes):** Tìm hiểu thư viện lạ, kiểm toán hệ thống cũ (legacy), hoặc đọc tài liệu mà không làm rác cửa sổ ngữ cảnh của Agent cha.
+  - **Kiểm toán chất lượng chuyên biệt:** Kiểm toán lỗ hổng bảo mật độc lập, đánh giá khả năng tiếp cận (accessibility - a11y), hoặc rà soát lint/format nghiêm ngặt.
+  - **Viết kiểm thử trực giao độc lập:** Viết các bài kiểm thử đơn vị độc lập hoặc fixtures khung test cho một hợp đồng giao diện đã được đóng băng.
+  - **Thực thi các lát cắt song song, không chồng chéo:** Triển khai các thành phần độc lập tác động lên các ranh giới tệp riêng biệt hoàn toàn.
+
+  ### Khi nào Agent cha BẮT BUỘC tự thực hiện (KHÔNG phân công):
+  - **Đánh đổi & Ra quyết định kiến trúc:** Soạn thảo các phương án trong `decision.md` và trình ký Gate 1.
+  - **Hợp đồng Task Master & Lập kế hoạch:** Định nghĩa `task.md`, hợp đồng lát cắt trong `plan.md` và trình ký Gate 2.
+  - **Cổng chất lượng & Phê duyệt của người dùng:** Thực hiện kiểm toán Gate 3 và sinh bản bàn giao cuối cùng `handoff.md`.
+  - **Tương tác làm rõ với người dùng:** Bất kỳ trao đổi nào cần sự định hướng hoặc phê duyệt trực tiếp từ con người.
+</delegation_criteria>
+
+---
+
+## 2. Ranh Giới Ngữ Cảnh & Quy Tắc Khoanh Vùng (Context Containment)
+
+<context_containment>
+  <rule id="explicit_file_manifest">
+    Luôn cung cấp cho subagent danh sách đường dẫn tệp cụ thể cần đọc hoặc chỉnh sửa. Tuyệt đối không ra lệnh mơ hồ như "hãy khám phá dự án" hay "quét toàn bộ codebase".
+  </rule>
+
+  <rule id="port_and_interface_focus">
+    Giới hạn dữ liệu đầu vào của subagent trong phạm vi các giao diện cổng (port interfaces), thực thể domain và bộ test đi kèm. Tránh đưa các chi tiết hạ tầng không cần thiết vào prompt của subagent.
+  </rule>
+
+  <rule id="structured_output_contract">
+    Luôn yêu cầu định dạng đầu ra có cấu trúc từ subagent (ví dụ: unified git diff, danh sách phát hiện phân loại theo Confirmed/Observed/Hypothesized, hoặc bảng markdown).
+  </rule>
+</context_containment>
+
+---
+
+## 3. Đồng Thời, Cách Ly & Quyền Ghi File (Concurrency & Isolation)
+
+<concurrency_and_isolation>
+  <rule id="zero_write_collision">
+    Nhiều subagent TUYỆT ĐỐI KHÔNG BAO GIỜ được cấp quyền ghi vào cùng một file hoặc cùng một bảng cơ sở dữ liệu đồng thời. Sửa đè file gây ra xung đột merge và lỗi hồi quy âm thầm.
+  </rule>
+
+  <rule id="read_only_by_default">
+    Mặc định subagent ở chế độ CHỈ ĐỌC (read-only) bất cứ khi nào có thể (khảo sát, đọc code, kiểm toán). Chỉ cấp quyền ghi khi các file mục tiêu hoàn toàn độc lập và thuộc quyền quản lý của riêng subagent đó.
+  </rule>
+
+  <rule id="workspace_isolation">
+    Nếu môi trường hỗ trợ không gian làm việc cách ly (branch hoặc worktree mode), hãy sử dụng để thử nghiệm các spike thăm dò nhằm bảo vệ cây làm việc chính luôn sạch sẽ.
+  </rule>
+</concurrency_and_isolation>
+
+---
+
+## 4. Đồng Bộ Trạng Thái & Tích Hợp Lại Về Agent Cha (State Synchronization)
+
+<state_synchronization>
+  <rule id="parent_owns_master_state">
+    Subagent TUYỆT ĐỐI KHÔNG trực tiếp chỉnh sửa các artifact quản lý của Agent cha (`task.md`, `state.md`, `review.md`). Chỉ Agent cha mới có thẩm quyền tổng hợp kết quả của subagent vào các tệp trạng thái master.
+  </rule>
+
+  <rule id="verification_before_acceptance">
+    Khi subagent trả về mã nguồn đã sửa đổi hoặc kết quả khảo sát, Agent cha phải trực tiếp kiểm tra git diff và chạy lệnh verifier của lát cắt tương ứng trước khi chấp nhận kết quả.
+  </rule>
+
+  <rule id="evidence_crystallization">
+    Trích xuất các bằng chứng đã xác minh từ báo cáo của subagent và ghi vào `state.md > <verification_evidence>`. Loại bỏ các log hội thoại tạm thời của subagent để bảo vệ sự tinh gọn của ngữ cảnh.
+  </rule>
+</state_synchronization>
+
+---
+
+## 5. Điều Phối Phản Ứng, Giới Hạn & Phục Hồi Lỗi (Coordination & Recovery)
+
+<coordination_and_recovery>
+  <rule id="no_polling_loops">
+    Tuyệt đối không viết vòng lặp kiểm tra trạng thái (`while true; sleep 5; check_status`) để chờ subagent. Dựa vào cơ chế đánh thức qua tin nhắn phản ứng (reactive message wakeup) của hệ thống khi subagent hoàn thành.
   </rule>
 
-  <rule id="context_containment">
-    Không cấp quyền truy cập repository không giới hạn; giới hạn ngữ cảnh của subagent trong phạm vi các bộ test suite liên quan và hợp đồng giao diện cổng.
+  <rule id="retry_budget_enforcement">
+    Nếu subagent gặp lỗi công cụ hoặc thất bại lặp đi lặp lại, áp dụng nghiêm ngặt ngân sách thử lại tối đa 3 lần. Nếu cạn ngân sách, ghi dấu vết lỗi vào `state.md > <failure_memory>` và dừng lại báo cáo người dùng.
   </rule>
 
-  <rule id="no_polling">
-    Dựa vào cơ chế đánh thức qua tin nhắn phản ứng (reactive message wakeup) của hệ thống khi subagent hoàn thành việc thực thi.
+  <rule id="teardown_and_cleanup">
+    Giải phóng sạch sẽ các subagent nhàn rỗi hoặc bị lỗi. Đảm bảo toàn bộ tệp nháp tạm thời (scratch) hoặc branch thử nghiệm do subagent tạo ra được dọn dẹp trước khi hoàn thành lát cắt.
   </rule>
-</delegation_rules>
+</coordination_and_recovery>
 
 </orchestration_protocol>