chore(i18n): refresh vi translations

docs/vi/ci.md

@@ -1,75 +1,75 @@
 ---
 read_when:
     - Bạn cần hiểu lý do một tác vụ CI đã chạy hoặc không chạy
-    - Bạn đang gỡ lỗi một lượt kiểm tra GitHub Actions không thành công
+    - Bạn đang gỡ lỗi một kiểm tra GitHub Actions không thành công
     - Bạn đang điều phối một lượt chạy hoặc chạy lại xác thực bản phát hành
-summary: Đồ thị công việc CI, các cổng phạm vi, nhóm bao quát phát hành và các lệnh cục bộ tương đương
+summary: Sơ đồ công việc CI, các cổng theo phạm vi, các nhóm bao quát phát hành và các lệnh cục bộ tương đương
 title: Quy trình CI
 x-i18n:
-    generated_at: "2026-04-30T09:34:52Z"
+    generated_at: "2026-04-30T18:38:49Z"
     model: gpt-5.5
     provider: openai
-    source_hash: a9c18f0801864ca1030aac9ea81117b011bd7936388984a1809ce3ae6e906e62
+    source_hash: a24afc27606ac7f4e9ead89acdd319bffa23336610f8a6cd8b576ea1a5b233dd
     source_path: ci.md
     workflow: 16
 ---
 
-OpenClaw CI chạy trên mọi lần push vào `main` và mọi pull request. Job `preflight` phân loại diff và tắt các lane tốn kém khi chỉ có các khu vực không liên quan thay đổi. Các lần chạy thủ công bằng `workflow_dispatch` cố ý bỏ qua phạm vi thông minh và mở rộng toàn bộ đồ thị cho release candidate và xác thực diện rộng. Các lane Android vẫn là tùy chọn thông qua `include_android`. Phạm vi kiểm tra Plugin chỉ dành cho phát hành nằm trong workflow [`Plugin Prerelease`](#plugin-prerelease) riêng và chỉ chạy từ [`Full Release Validation`](#full-release-validation) hoặc một lần dispatch thủ công rõ ràng.
+OpenClaw CI chạy trên mọi lần push vào `main` và mọi pull request. Job `preflight` phân loại diff và tắt các lane tốn kém khi chỉ những khu vực không liên quan thay đổi. Các lần chạy `workflow_dispatch` thủ công cố ý bỏ qua phạm vi thông minh và mở rộng toàn bộ đồ thị cho các release candidate và kiểm định rộng. Các lane Android vẫn là tùy chọn thông qua `include_android`. Phạm vi kiểm thử Plugin chỉ dành cho phát hành nằm trong workflow [`Plugin Tiền phát hành`](#plugin-prerelease) riêng và chỉ chạy từ [`Kiểm định Bản phát hành Đầy đủ`](#full-release-validation) hoặc một dispatch thủ công rõ ràng.
 
 ## Tổng quan pipeline
 
-| Job                              | Mục đích                                                                                      | Khi chạy                       |
-| -------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------- |
-| `preflight`                      | Phát hiện thay đổi chỉ trong tài liệu, phạm vi đã thay đổi, extension đã thay đổi và xây dựng manifest CI      | Luôn chạy trên push và PR không phải draft |
-| `security-scm-fast`              | Phát hiện khóa riêng tư và kiểm toán workflow qua `zizmor`                                        | Luôn chạy trên push và PR không phải draft |
-| `security-dependency-audit`      | Kiểm toán lockfile production không cần dependency dựa trên advisory npm                             | Luôn chạy trên push và PR không phải draft |
-| `security-fast`                  | Tổng hợp bắt buộc cho các job bảo mật nhanh                                                | Luôn chạy trên push và PR không phải draft |
-| `check-dependencies`             | Lượt kiểm tra Knip chỉ dành cho dependency production cùng bộ bảo vệ danh sách cho phép tệp không dùng                    | Thay đổi liên quan đến Node              |
-| `build-artifacts`                | Build `dist/`, Control UI, kiểm tra artifact đã build và artifact downstream có thể tái sử dụng          | Thay đổi liên quan đến Node              |
-| `checks-fast-core`               | Các lane kiểm tra đúng đắn nhanh trên Linux như kiểm tra bundled/plugin-contract/protocol                 | Thay đổi liên quan đến Node              |
-| `checks-fast-contracts-channels` | Kiểm tra contract channel được chia shard với kết quả kiểm tra tổng hợp ổn định                         | Thay đổi liên quan đến Node              |
-| `checks-node-core-test`          | Các shard kiểm thử Node lõi, loại trừ lane channel, bundled, contract và extension             | Thay đổi liên quan đến Node              |
-| `check`                          | Tương đương cổng local chính được chia shard: kiểu production, lint, guard, kiểu test và smoke nghiêm ngặt   | Thay đổi liên quan đến Node              |
-| `check-additional`               | Các shard kiến trúc, boundary, guard bề mặt extension, package-boundary và gateway-watch | Thay đổi liên quan đến Node              |
-| `build-smoke`                    | Kiểm thử smoke CLI đã build và smoke bộ nhớ khởi động                                               | Thay đổi liên quan đến Node              |
-| `checks`                         | Bộ xác minh cho kiểm thử channel artifact đã build                                                    | Thay đổi liên quan đến Node              |
-| `checks-node-compat-node22`      | Lane build và smoke tương thích Node 22                                                   | Dispatch CI thủ công cho phát hành    |
-| `check-docs`                     | Định dạng tài liệu, lint và kiểm tra liên kết hỏng                                                | Tài liệu thay đổi                       |
-| `skills-python`                  | Ruff + pytest cho Skills dựa trên Python                                                       | Thay đổi liên quan đến Python-skill      |
-| `checks-windows`                 | Kiểm thử process/path riêng cho Windows cùng hồi quy specifier import runtime dùng chung         | Thay đổi liên quan đến Windows           |
-| `macos-node`                     | Lane kiểm thử TypeScript trên macOS dùng artifact đã build dùng chung                                  | Thay đổi liên quan đến macOS             |
-| `macos-swift`                    | Swift lint, build và test cho ứng dụng macOS                                               | Thay đổi liên quan đến macOS             |
-| `android`                        | Kiểm thử đơn vị Android cho cả hai flavor cộng một bản build debug APK                                 | Thay đổi liên quan đến Android           |
-| `test-performance-agent`         | Tối ưu hóa kiểm thử chậm hằng ngày bằng Codex sau hoạt động đáng tin cậy                                    | CI main thành công hoặc dispatch thủ công |
+| Job                              | Mục đích                                                                                     | Khi chạy                            |
+| -------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------- |
+| `preflight`                      | Phát hiện thay đổi chỉ ở docs, phạm vi đã thay đổi, plugin đã thay đổi, và xây dựng manifest CI | Luôn chạy trên push và PR không phải draft |
+| `security-scm-fast`              | Phát hiện khóa riêng tư và kiểm toán workflow qua `zizmor`                                   | Luôn chạy trên push và PR không phải draft |
+| `security-dependency-audit`      | Kiểm toán lockfile production không cần dependency theo advisory của npm                      | Luôn chạy trên push và PR không phải draft |
+| `security-fast`                  | Tổng hợp bắt buộc cho các job bảo mật nhanh                                                  | Luôn chạy trên push và PR không phải draft |
+| `check-dependencies`             | Lượt kiểm tra Knip chỉ dành cho dependency production cộng với guard allowlist tệp không dùng | Thay đổi liên quan đến Node         |
+| `build-artifacts`                | Build `dist/`, Control UI, kiểm tra artifact đã build, và artifact dùng lại cho downstream    | Thay đổi liên quan đến Node         |
+| `checks-fast-core`               | Các lane tính đúng đắn nhanh trên Linux như kiểm tra bundled/plugin-contract/protocol         | Thay đổi liên quan đến Node         |
+| `checks-fast-contracts-channels` | Kiểm tra contract channel theo shard với kết quả kiểm tra tổng hợp ổn định                   | Thay đổi liên quan đến Node         |
+| `checks-node-core-test`          | Các shard test Node lõi, loại trừ lane channel, bundled, contract, và plugin                 | Thay đổi liên quan đến Node         |
+| `check`                          | Tương đương gate cục bộ chính theo shard: type prod, lint, guard, type test, và smoke nghiêm ngặt | Thay đổi liên quan đến Node         |
+| `check-additional`               | Các shard architecture, boundary, guard bề mặt plugin, package-boundary, và gateway-watch     | Thay đổi liên quan đến Node         |
+| `build-smoke`                    | Smoke test CLI đã build và smoke bộ nhớ khởi động                                            | Thay đổi liên quan đến Node         |
+| `checks`                         | Bộ xác minh cho các test channel artifact đã build                                           | Thay đổi liên quan đến Node         |
+| `checks-node-compat-node22`      | Lane build và smoke tương thích Node 22                                                      | Dispatch CI thủ công cho phát hành  |
+| `check-docs`                     | Định dạng docs, lint, và kiểm tra link hỏng                                                  | Docs thay đổi                       |
+| `skills-python`                  | Ruff + pytest cho skills dựa trên Python                                                     | Thay đổi liên quan đến skill Python |
+| `checks-windows`                 | Test process/path riêng cho Windows cộng với hồi quy shared runtime import specifier         | Thay đổi liên quan đến Windows      |
+| `macos-node`                     | Lane test TypeScript macOS dùng các artifact đã build dùng chung                             | Thay đổi liên quan đến macOS        |
+| `macos-swift`                    | Swift lint, build, và test cho ứng dụng macOS                                                | Thay đổi liên quan đến macOS        |
+| `android`                        | Unit test Android cho cả hai flavor cộng với một bản build debug APK                         | Thay đổi liên quan đến Android      |
+| `test-performance-agent`         | Tối ưu hóa test chậm hằng ngày bằng Codex sau hoạt động tin cậy                              | CI main thành công hoặc dispatch thủ công |
 
 ## Thứ tự fail-fast
 
-1. `preflight` quyết định những lane nào tồn tại. Logic `docs-scope` và `changed-scope` là các bước bên trong job này, không phải các job độc lập.
-2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` và `skills-python` thất bại nhanh mà không chờ các job artifact và ma trận nền tảng nặng hơn.
-3. `build-artifacts` chạy chồng lấp với các lane Linux nhanh để consumer downstream có thể bắt đầu ngay khi bản build dùng chung sẵn sàng.
-4. Các lane nền tảng và runtime nặng hơn mở rộng sau đó: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` và `android`.
+1. `preflight` quyết định lane nào tồn tại. Logic `docs-scope` và `changed-scope` là các bước bên trong job này, không phải job độc lập.
+2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs`, và `skills-python` thất bại nhanh mà không chờ các job artifact và ma trận nền tảng nặng hơn.
+3. `build-artifacts` chạy chồng lấp với các lane Linux nhanh để downstream consumer có thể bắt đầu ngay khi bản build dùng chung sẵn sàng.
+4. Các lane nền tảng và runtime nặng hơn mở rộng sau đó: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift`, và `android`.
 
-GitHub có thể đánh dấu các job bị thay thế là `cancelled` khi một push mới hơn được đưa lên cùng PR hoặc ref `main`. Hãy xem đó là nhiễu CI trừ khi lần chạy mới nhất cho cùng ref cũng đang thất bại. Các kiểm tra shard tổng hợp dùng `!cancelled() && always()` để vẫn báo cáo lỗi shard bình thường nhưng không xếp hàng sau khi toàn bộ workflow đã bị thay thế. Khóa đồng thời CI tự động được version hóa (`CI-v7-*`) để một zombie phía GitHub trong nhóm hàng đợi cũ không thể chặn vô thời hạn các lần chạy main mới hơn. Các lần chạy thủ công toàn bộ bộ kiểm thử dùng `CI-manual-v1-*` và không hủy các lần chạy đang tiến hành.
+GitHub có thể đánh dấu các job bị thay thế là `cancelled` khi có push mới hơn vào cùng PR hoặc ref `main`. Hãy coi đó là nhiễu CI trừ khi lần chạy mới nhất cho cùng ref cũng đang thất bại. Các kiểm tra shard tổng hợp dùng `!cancelled() && always()` để vẫn báo lỗi shard bình thường nhưng không xếp hàng sau khi toàn bộ workflow đã bị thay thế. Khóa concurrency CI tự động được đánh phiên bản (`CI-v7-*`) để một zombie phía GitHub trong nhóm hàng đợi cũ không thể chặn vô hạn các lần chạy main mới hơn. Các lần chạy full-suite thủ công dùng `CI-manual-v1-*` và không hủy các lần chạy đang tiến hành.
 
 ## Phạm vi và định tuyến
 
-Logic phạm vi nằm trong `scripts/ci-changed-scope.mjs` và được bao phủ bởi kiểm thử đơn vị trong `src/scripts/ci-changed-scope.test.ts`. Dispatch thủ công bỏ qua phát hiện changed-scope và khiến manifest preflight hoạt động như thể mọi khu vực có phạm vi đều đã thay đổi.
+Logic phạm vi nằm trong `scripts/ci-changed-scope.mjs` và được bao phủ bởi unit test trong `src/scripts/ci-changed-scope.test.ts`. Dispatch thủ công bỏ qua phát hiện changed-scope và khiến manifest preflight hoạt động như thể mọi khu vực có phạm vi đều đã thay đổi.
 
-- **Chỉnh sửa workflow CI** xác thực đồ thị CI Node cộng với lint workflow, nhưng tự chúng không ép build native Windows, Android hoặc macOS; các lane nền tảng đó vẫn được giới hạn theo thay đổi mã nguồn nền tảng.
-- **Chỉnh sửa chỉ định tuyến CI, một số chỉnh sửa fixture core-test rẻ được chọn và chỉnh sửa helper/test-routing contract Plugin hẹp** dùng đường dẫn manifest nhanh chỉ dành cho Node: `preflight`, bảo mật và một tác vụ `checks-fast-core` duy nhất. Đường dẫn đó bỏ qua build artifact, tương thích Node 22, contract channel, toàn bộ shard lõi, shard bundled-plugin và các ma trận guard bổ sung khi thay đổi chỉ giới hạn ở các bề mặt định tuyến hoặc helper mà tác vụ nhanh trực tiếp thực thi.
-- **Kiểm tra Node trên Windows** được giới hạn vào wrapper process/path riêng cho Windows, helper runner npm/pnpm/UI, cấu hình trình quản lý package và các bề mặt workflow CI thực thi lane đó; mã nguồn, Plugin, install-smoke và thay đổi chỉ dành cho test không liên quan vẫn nằm trên các lane Node Linux.
+- **Chỉnh sửa workflow CI** xác thực đồ thị CI Node cộng với lint workflow, nhưng tự chúng không ép build native Windows, Android, hoặc macOS; các lane nền tảng đó vẫn được giới hạn theo thay đổi mã nguồn nền tảng.
+- **Chỉnh sửa chỉ định tuyến CI, chỉnh sửa fixture core-test rẻ được chọn, và chỉnh sửa helper/test-routing contract Plugin hẹp** dùng đường dẫn manifest nhanh chỉ dành cho Node: `preflight`, bảo mật, và một task `checks-fast-core` duy nhất. Đường dẫn đó bỏ qua build artifact, tương thích Node 22, contract channel, shard lõi đầy đủ, shard bundled-plugin, và ma trận guard bổ sung khi thay đổi chỉ giới hạn ở các bề mặt định tuyến hoặc helper mà task nhanh trực tiếp thực thi.
+- **Kiểm tra Node Windows** được giới hạn ở wrapper process/path riêng cho Windows, helper runner npm/pnpm/UI, cấu hình package manager, và các bề mặt workflow CI thực thi lane đó; các thay đổi mã nguồn, Plugin, install-smoke, và chỉ test không liên quan vẫn ở các lane Node Linux.
 
-Các nhóm kiểm thử Node chậm nhất được tách hoặc cân bằng để mỗi job vẫn nhỏ mà không giữ runner quá mức: contract channel chạy thành ba shard có trọng số, các lane unit lõi nhỏ được ghép cặp, auto-reply chạy thành bốn worker cân bằng (với subtree reply được tách thành các shard agent-runner, dispatch và commands/state-routing), và cấu hình agentic gateway/plugin được phân bổ trên các job Node agentic chỉ dùng mã nguồn hiện có thay vì chờ artifact đã build. Các kiểm thử trình duyệt, QA, media và Plugin khác diện rộng dùng cấu hình Vitest chuyên dụng thay vì catch-all Plugin dùng chung. Các shard include-pattern ghi lại mục timing bằng tên shard CI, để `.artifacts/vitest-shard-timings.json` có thể phân biệt toàn bộ cấu hình với một shard đã lọc. `check-additional` giữ công việc compile/canary package-boundary cùng nhau và tách kiến trúc topology runtime khỏi phạm vi gateway watch; shard boundary guard chạy đồng thời các guard độc lập nhỏ của nó trong một job. Gateway watch, kiểm thử channel và shard support-boundary lõi chạy đồng thời bên trong `build-artifacts` sau khi `dist/` và `dist-runtime/` đã được build.
+Các họ test Node chậm nhất được tách hoặc cân bằng để mỗi job vẫn nhỏ mà không giữ runner quá mức: contract channel chạy dưới dạng ba shard có trọng số, các lane unit lõi nhỏ được ghép đôi, auto-reply chạy dưới dạng bốn worker cân bằng (với subtree reply được tách thành các shard agent-runner, dispatch, và commands/state-routing), và cấu hình gateway/Plugin có tính agentic được phân bổ trên các job Node agentic chỉ nguồn hiện có thay vì chờ artifact đã build. Các test trình duyệt rộng, QA, media, và Plugin linh tinh dùng cấu hình Vitest chuyên dụng của chúng thay vì catch-all Plugin dùng chung. Các shard include-pattern ghi mục timing bằng tên shard CI, để `.artifacts/vitest-shard-timings.json` có thể phân biệt cả một cấu hình với một shard đã lọc. `check-additional` giữ công việc compile/canary package-boundary cùng nhau và tách architecture topology runtime khỏi phạm vi gateway watch; shard guard boundary chạy các guard độc lập nhỏ của nó đồng thời trong một job. Gateway watch, test channel, và shard support-boundary lõi chạy đồng thời bên trong `build-artifacts` sau khi `dist/` và `dist-runtime/` đã được build.
 
-Android CI chạy cả `testPlayDebugUnitTest` và `testThirdPartyDebugUnitTest` rồi build Play debug APK. Flavor bên thứ ba không có source set hoặc manifest riêng; lane unit-test của nó vẫn compile flavor với các cờ BuildConfig SMS/call-log, đồng thời tránh một job đóng gói debug APK trùng lặp trên mỗi push liên quan đến Android.
+Android CI chạy cả `testPlayDebugUnitTest` và `testThirdPartyDebugUnitTest` rồi build Play debug APK. Flavor bên thứ ba không có source set hoặc manifest riêng; lane unit-test của nó vẫn compile flavor với các cờ BuildConfig SMS/call-log, trong khi tránh job đóng gói debug APK trùng lặp trên mỗi push liên quan đến Android.
 
-Shard `check-dependencies` chạy `pnpm deadcode:dependencies` (một lượt Knip chỉ dành cho dependency production được pin vào phiên bản Knip mới nhất, với tuổi phát hành tối thiểu của pnpm bị tắt cho cài đặt `dlx`) và `pnpm deadcode:unused-files`, so sánh các phát hiện tệp production không dùng của Knip với `scripts/deadcode-unused-files.allowlist.mjs`. Guard tệp không dùng thất bại khi một PR thêm tệp không dùng mới chưa được review hoặc để lại mục allowlist đã lỗi thời, đồng thời giữ lại các bề mặt Plugin động có chủ ý, generated, build, live-test và package bridge mà Knip không thể phân giải tĩnh.
+Shard `check-dependencies` chạy `pnpm deadcode:dependencies` (một lượt kiểm tra Knip chỉ dành cho dependency production được ghim vào phiên bản Knip mới nhất, với tuổi phát hành tối thiểu của pnpm bị tắt cho cài đặt `dlx`) và `pnpm deadcode:unused-files`, so sánh phát hiện tệp production không dùng của Knip với `scripts/deadcode-unused-files.allowlist.mjs`. Guard tệp không dùng thất bại khi một PR thêm tệp không dùng mới chưa được review hoặc để lại mục allowlist lỗi thời, trong khi vẫn giữ các bề mặt Plugin động có chủ ý, được tạo sinh, build, live-test, và cầu nối package mà Knip không thể phân giải tĩnh.
 
 ## Dispatch thủ công
 
-Các dispatch CI thủ công chạy cùng đồ thị job như CI bình thường nhưng buộc mọi lane có phạm vi không phải Android bật: shard Node Linux, shard bundled-plugin, contract channel, tương thích Node 22, `check`, `check-additional`, build smoke, kiểm tra tài liệu, Python skills, Windows, macOS và Control UI i18n. Dispatch CI thủ công độc lập chỉ chạy Android với `include_android=true`; umbrella phát hành đầy đủ bật Android bằng cách truyền `include_android=true`. Kiểm tra tĩnh prerelease Plugin, shard `agentic-plugins` chỉ dành cho phát hành, lượt quét batch extension đầy đủ và lane Docker prerelease Plugin bị loại khỏi CI. Bộ Docker prerelease chỉ chạy khi `Full Release Validation` dispatch workflow `Plugin Prerelease` riêng với cổng release-validation được bật.
+Các dispatch CI thủ công chạy cùng đồ thị job như CI bình thường nhưng ép mọi lane có phạm vi không phải Android bật: shard Linux Node, shard bundled-plugin, contract channel, tương thích Node 22, `check`, `check-additional`, build smoke, kiểm tra docs, Python skills, Windows, macOS, và Control UI i18n. Các dispatch CI thủ công độc lập chỉ chạy Android với `include_android=true`; umbrella phát hành đầy đủ bật Android bằng cách truyền `include_android=true`. Kiểm tra tĩnh Plugin prerelease, shard `agentic-plugins` chỉ dành cho phát hành, lượt quét batch Plugin đầy đủ, và các lane Docker Plugin prerelease bị loại khỏi CI. Bộ Docker prerelease chỉ chạy khi `Full Release Validation` dispatch workflow `Plugin Prerelease` riêng với gate release-validation được bật.
 
-Các lần chạy thủ công dùng một nhóm đồng thời duy nhất để một bộ kiểm thử đầy đủ cho release-candidate không bị hủy bởi một lần push hoặc PR khác trên cùng ref. Input tùy chọn `target_ref` cho phép caller đáng tin cậy chạy đồ thị đó trên một nhánh, tag hoặc SHA commit đầy đủ trong khi dùng tệp workflow từ ref dispatch đã chọn.
+Các lần chạy thủ công dùng một nhóm concurrency duy nhất để full suite release-candidate không bị hủy bởi một lần chạy push hoặc PR khác trên cùng ref. Input `target_ref` tùy chọn cho phép caller đáng tin cậy chạy đồ thị đó trên một branch, tag, hoặc SHA commit đầy đủ trong khi dùng tệp workflow từ ref dispatch đã chọn.
 
 ```bash
 gh workflow run ci.yml --ref release/YYYY.M.D
@@ -79,17 +79,17 @@ gh workflow run full-release-validation.yml --ref main -f ref=<branch-or-sha>
 
 ## Runner
 
-| Bộ chạy                         | Công việc                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
-| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `ubuntu-24.04`                   | `preflight`, các công việc bảo mật nhanh và tổng hợp (`security-scm-fast`, `security-dependency-audit`, `security-fast`), các kiểm tra protocol/contract/bundled nhanh, kiểm tra contract kênh theo shard, các shard `check` trừ lint, các shard và tổng hợp `check-additional`, trình xác minh tổng hợp kiểm thử Node, kiểm tra tài liệu, Python skills, workflow-sanity, labeler, auto-response; preflight install-smoke cũng dùng Ubuntu do GitHub lưu trữ để ma trận Blacksmith có thể xếp hàng sớm hơn |
-| `blacksmith-4vcpu-ubuntu-2404`   | `CodeQL Critical Quality`, các shard extension nhẹ hơn, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types`, và `check-test-types`                                                                                                                                                                                                                                                                                                                       |
-| `blacksmith-8vcpu-ubuntu-2404`   | `build-artifacts`, build-smoke, các shard kiểm thử Linux Node, các shard kiểm thử plugin bundled, `android`                                                                                                                                                                                                                                                                                                                                                             |
-| `blacksmith-16vcpu-ubuntu-2404`  | `check-lint` (nhạy với CPU đến mức 8 vCPU tốn nhiều chi phí hơn phần tiết kiệm được); các bản dựng Docker install-smoke (thời gian xếp hàng 32-vCPU tốn nhiều chi phí hơn phần tiết kiệm được)                                                                                                                                                                                                                                                                           |
-| `blacksmith-16vcpu-windows-2025` | `checks-windows`                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
-| `blacksmith-6vcpu-macos-latest`  | `macos-node` trên `openclaw/openclaw`; các fork quay về dùng `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                             |
-| `blacksmith-12vcpu-macos-latest` | `macos-swift` trên `openclaw/openclaw`; các fork quay về dùng `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                            |
+| Trình chạy                       | Công việc                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
+| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `ubuntu-24.04`                   | `preflight`, các công việc bảo mật nhanh và các tổng hợp (`security-scm-fast`, `security-dependency-audit`, `security-fast`), các kiểm tra nhanh về giao thức/hợp đồng/đóng gói sẵn, các kiểm tra hợp đồng kênh được chia shard, các shard `check` ngoại trừ lint, các shard và tổng hợp `check-additional`, các bộ xác minh tổng hợp kiểm thử Node, kiểm tra tài liệu, Python skills, workflow-sanity, labeler, auto-response; preflight install-smoke cũng dùng Ubuntu do GitHub lưu trữ để ma trận Blacksmith có thể xếp hàng sớm hơn |
+| `blacksmith-4vcpu-ubuntu-2404`   | `CodeQL Critical Quality`, các shard Plugin có trọng lượng thấp hơn, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types`, và `check-test-types`                                                                                                                                                                                                                                                                                                                            |
+| `blacksmith-8vcpu-ubuntu-2404`   | `build-artifacts`, build-smoke, các shard kiểm thử Node trên Linux, các shard kiểm thử Plugin đóng gói sẵn, `android`                                                                                                                                                                                                                                                                                                                                                                      |
+| `blacksmith-16vcpu-ubuntu-2404`  | `check-lint` (đủ nhạy với CPU đến mức 8 vCPU tốn nhiều hơn phần tiết kiệm được); các bản dựng Docker install-smoke (thời gian xếp hàng 32-vCPU tốn nhiều hơn phần tiết kiệm được)                                                                                                                                                                                                                                                                                                          |
+| `blacksmith-16vcpu-windows-2025` | `checks-windows`                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| `blacksmith-6vcpu-macos-latest`  | `macos-node` trên `openclaw/openclaw`; các fork quay về `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                                     |
+| `blacksmith-12vcpu-macos-latest` | `macos-swift` trên `openclaw/openclaw`; các fork quay về `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                                    |
 
-## Lệnh tương đương cục bộ
+## Các lệnh tương đương cục bộ
 
 ```bash
 pnpm changed:lanes                            # inspect the local changed-lane classifier for origin/main...HEAD
@@ -117,27 +117,27 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac
 
 ## Xác thực phát hành đầy đủ
 
-`Full Release Validation` là workflow bao trùm thủ công cho việc "chạy mọi thứ trước khi phát hành." Nó nhận một nhánh, tag hoặc SHA commit đầy đủ, dispatch workflow `CI` thủ công với mục tiêu đó, dispatch `Plugin Prerelease` cho bằng chứng chỉ dành cho phát hành về plugin/package/static/Docker, và dispatch `OpenClaw Release Checks` cho install smoke, package acceptance, các bộ kiểm thử đường dẫn phát hành Docker, live/E2E, OpenWebUI, QA Lab parity, Matrix và các lane Telegram. Nó cũng có thể chạy workflow hậu xuất bản `NPM Telegram Beta E2E` khi một thông số gói đã xuất bản được cung cấp.
+`Full Release Validation` là workflow bao trùm thủ công cho việc "chạy mọi thứ trước khi phát hành." Nó chấp nhận một nhánh, thẻ hoặc SHA commit đầy đủ, dispatch workflow `CI` thủ công với đích đó, dispatch `Plugin Prerelease` cho bằng chứng chỉ dành cho phát hành về Plugin/gói/tĩnh/Docker, và dispatch `OpenClaw Release Checks` cho kiểm tra cài đặt, chấp nhận gói, các bộ kiểm thử đường dẫn phát hành Docker, live/E2E, OpenWebUI, tương đồng QA Lab, Matrix và các làn Telegram. Nó cũng có thể chạy workflow `NPM Telegram Beta E2E` sau phát hành khi có thông số gói đã phát hành được cung cấp.
 
-`release_profile` kiểm soát độ rộng live/provider được truyền vào release checks:
+`release_profile` kiểm soát phạm vi live/nhà cung cấp được truyền vào kiểm tra phát hành:
 
-- `minimum` giữ các lane OpenAI/core nhanh nhất và trọng yếu cho phát hành.
-- `stable` thêm tập provider/backend ổn định.
-- `full` chạy ma trận provider/media tư vấn rộng.
+- `minimum` giữ các làn OpenAI/lõi quan trọng với phát hành nhanh nhất.
+- `stable` thêm tập nhà cung cấp/backend ổn định.
+- `full` chạy ma trận nhà cung cấp/phương tiện tư vấn rộng.
 
-Workflow bao trùm ghi lại id của các lần chạy con đã dispatch, và công việc cuối cùng `Verify full validation` kiểm tra lại kết luận hiện tại của các lần chạy con rồi nối thêm các bảng công việc chậm nhất cho từng lần chạy con. Nếu một workflow con được chạy lại và chuyển xanh, chỉ chạy lại công việc xác minh cha để làm mới kết quả bao trùm và bản tóm tắt thời gian.
+Workflow bao trùm ghi lại các id lần chạy con đã dispatch, và công việc `Verify full validation` cuối cùng kiểm tra lại kết luận hiện tại của các lần chạy con rồi thêm các bảng công việc chậm nhất cho từng lần chạy con. Nếu một workflow con được chạy lại và chuyển xanh, chỉ chạy lại công việc xác minh cha để làm mới kết quả bao trùm và tóm tắt thời gian.
 
-Để khôi phục, cả `Full Release Validation` và `OpenClaw Release Checks` đều nhận `rerun_group`. Dùng `all` cho một release candidate, `ci` chỉ cho CI con đầy đủ thông thường, `release-checks` cho mọi công việc con phát hành, hoặc một nhóm hẹp hơn: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live`, hoặc `npm-telegram` trên workflow bao trùm. Cách này giữ phạm vi chạy lại của một hộp phát hành bị lỗi sau một bản sửa tập trung.
+Để khôi phục, cả `Full Release Validation` và `OpenClaw Release Checks` đều chấp nhận `rerun_group`. Dùng `all` cho một ứng viên phát hành, `ci` chỉ cho phần con CI đầy đủ thông thường, `release-checks` cho mọi phần con phát hành, hoặc một nhóm hẹp hơn: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live`, hoặc `npm-telegram` trên workflow bao trùm. Cách này giữ việc chạy lại hộp phát hành bị lỗi trong phạm vi giới hạn sau một bản sửa tập trung.
 
-`OpenClaw Release Checks` dùng workflow ref đáng tin cậy để phân giải ref đã chọn một lần thành tarball `release-package-under-test`, rồi truyền artifact đó cho cả workflow Docker đường dẫn phát hành live/E2E và shard package acceptance. Điều đó giữ byte của gói nhất quán trên các hộp phát hành và tránh đóng gói lại cùng một ứng viên trong nhiều công việc con.
+`OpenClaw Release Checks` dùng ref workflow đáng tin cậy để phân giải ref đã chọn một lần thành tarball `release-package-under-test`, rồi truyền artifact đó cho cả workflow Docker live/E2E theo đường dẫn phát hành và shard chấp nhận gói. Điều đó giữ byte của gói nhất quán trên các hộp phát hành và tránh đóng gói lại cùng một ứng viên trong nhiều công việc con.
 
-## Các shard live và E2E
+## Các shard Live và E2E
 
-Công việc con live/E2E của bản phát hành giữ độ phủ rộng của `pnpm test:live` native, nhưng chạy nó dưới dạng các shard có tên thông qua `scripts/test-live-shard.mjs` thay vì một công việc nối tiếp:
+Phần con live/E2E của phát hành giữ phạm vi bao phủ `pnpm test:live` gốc rộng, nhưng chạy nó dưới dạng các shard có tên thông qua `scripts/test-live-shard.mjs` thay vì một công việc tuần tự:
 
 - `native-live-src-agents`
 - `native-live-src-gateway-core`
-- các công việc `native-live-src-gateway-profiles` được lọc theo provider
+- các công việc `native-live-src-gateway-profiles` được lọc theo nhà cung cấp
 - `native-live-src-gateway-backends`
 - `native-live-test`
 - `native-live-extensions-a-k`
@@ -145,57 +145,57 @@ Công việc con live/E2E của bản phát hành giữ độ phủ rộng của
 - `native-live-extensions-openai`
 - `native-live-extensions-o-z-other`
 - `native-live-extensions-xai`
-- các shard media audio/video được tách riêng và các shard music được lọc theo provider
+- các shard phương tiện âm thanh/video được tách riêng và các shard nhạc được lọc theo nhà cung cấp
 
-Cách này giữ cùng độ phủ tệp trong khi giúp các lỗi provider live chậm dễ chạy lại và chẩn đoán hơn. Các tên shard tổng hợp `native-live-extensions-o-z`, `native-live-extensions-media`, và `native-live-extensions-media-music` vẫn hợp lệ cho các lần chạy lại thủ công một lần.
+Cách này giữ nguyên phạm vi bao phủ tệp trong khi giúp các lỗi nhà cung cấp live chậm dễ chạy lại và chẩn đoán hơn. Các tên shard tổng hợp `native-live-extensions-o-z`, `native-live-extensions-media`, và `native-live-extensions-media-music` vẫn hợp lệ cho các lần chạy lại thủ công một lần.
 
-Các shard media live native chạy trong `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, được dựng bởi workflow `Live Media Runner Image`. Image đó cài sẵn `ffmpeg` và `ffprobe`; các công việc media chỉ xác minh binary trước khi thiết lập. Giữ các bộ kiểm thử live dựa trên Docker trên runner Blacksmith bình thường — công việc container không phải nơi phù hợp để khởi chạy kiểm thử Docker lồng nhau.
+Các shard phương tiện live gốc chạy trong `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, được xây dựng bởi workflow `Live Media Runner Image`. Image đó cài sẵn `ffmpeg` và `ffprobe`; các công việc phương tiện chỉ xác minh các binary trước khi thiết lập. Giữ các bộ kiểm thử live dựa trên Docker trên các runner Blacksmith thông thường - công việc container không phải là nơi phù hợp để khởi chạy kiểm thử Docker lồng nhau.
 
-Các shard model/backend live dựa trên Docker dùng một image dùng chung riêng `ghcr.io/openclaw/openclaw-live-test:<sha>` cho mỗi commit đã chọn. Workflow phát hành live dựng và đẩy image đó một lần, sau đó các shard Docker live model, gateway, CLI backend, ACP bind và Codex harness chạy với `OPENCLAW_SKIP_DOCKER_BUILD=1`. Nếu các shard đó tự dựng lại target Docker nguồn đầy đủ một cách độc lập, lần chạy phát hành đã cấu hình sai và sẽ lãng phí thời gian thực trên các bản dựng image trùng lặp.
+Các shard live model/backend dựa trên Docker dùng một image dùng chung riêng `ghcr.io/openclaw/openclaw-live-test:<sha>` cho mỗi commit đã chọn. Workflow phát hành live xây dựng và đẩy image đó một lần, sau đó các shard Docker live model, Gateway, CLI backend, ACP bind và Codex harness chạy với `OPENCLAW_SKIP_DOCKER_BUILD=1`. Nếu các shard đó tự xây dựng lại đích Docker nguồn đầy đủ, lần chạy phát hành bị cấu hình sai và sẽ lãng phí thời gian thực trên các bản dựng image trùng lặp.
 
-## Package Acceptance
+## Chấp nhận gói
 
-Dùng `Package Acceptance` khi câu hỏi là "gói OpenClaw có thể cài đặt này có hoạt động như một sản phẩm không?" Nó khác với CI thông thường: CI thông thường xác thực cây nguồn, còn package acceptance xác thực một tarball duy nhất thông qua cùng harness Docker E2E mà người dùng thực hiện sau khi cài đặt hoặc cập nhật.
+Dùng `Package Acceptance` khi câu hỏi là "gói OpenClaw có thể cài đặt này có hoạt động như một sản phẩm không?" Nó khác với CI thông thường: CI thông thường xác thực cây nguồn, còn chấp nhận gói xác thực một tarball duy nhất thông qua cùng harness Docker E2E mà người dùng thực hiện sau khi cài đặt hoặc cập nhật.
 
 ### Công việc
 
-1. `resolve_package` checkout `workflow_ref`, phân giải một ứng viên gói, ghi `.artifacts/docker-e2e-package/openclaw-current.tgz`, ghi `.artifacts/docker-e2e-package/package-candidate.json`, tải cả hai lên dưới dạng artifact `package-under-test`, và in nguồn, workflow ref, package ref, phiên bản, SHA-256, và profile trong bản tóm tắt bước GitHub.
-2. `docker_acceptance` gọi `openclaw-live-and-e2e-checks-reusable.yml` với `ref=workflow_ref` và `package_artifact_name=package-under-test`. Workflow tái sử dụng tải artifact đó xuống, xác thực inventory tarball, chuẩn bị image Docker package-digest khi cần, và chạy các lane Docker đã chọn với gói đó thay vì đóng gói checkout của workflow. Khi một profile chọn nhiều `docker_lanes` được nhắm mục tiêu, workflow tái sử dụng chuẩn bị gói và image dùng chung một lần, rồi fan out các lane đó thành các công việc Docker nhắm mục tiêu song song với artifact duy nhất.
-3. `package_telegram` tùy chọn gọi `NPM Telegram Beta E2E`. Nó chạy khi `telegram_mode` không phải `none` và cài đặt cùng artifact `package-under-test` khi Package Acceptance đã phân giải một gói; dispatch Telegram độc lập vẫn có thể cài đặt một thông số npm đã xuất bản.
-4. `summary` làm workflow thất bại nếu phân giải gói, Docker acceptance, hoặc lane Telegram tùy chọn thất bại.
+1. `resolve_package` checkout `workflow_ref`, phân giải một ứng viên gói, ghi `.artifacts/docker-e2e-package/openclaw-current.tgz`, ghi `.artifacts/docker-e2e-package/package-candidate.json`, tải cả hai lên làm artifact `package-under-test`, và in nguồn, ref workflow, ref gói, phiên bản, SHA-256, và hồ sơ trong tóm tắt bước GitHub.
+2. `docker_acceptance` gọi `openclaw-live-and-e2e-checks-reusable.yml` với `ref=workflow_ref` và `package_artifact_name=package-under-test`. Workflow tái sử dụng tải xuống artifact đó, xác thực danh mục tarball, chuẩn bị các image Docker package-digest khi cần, và chạy các làn Docker đã chọn trên gói đó thay vì đóng gói checkout workflow. Khi một hồ sơ chọn nhiều `docker_lanes` có mục tiêu, workflow tái sử dụng chuẩn bị gói và image dùng chung một lần, rồi tỏa các làn đó ra thành các công việc Docker có mục tiêu chạy song song với artifact riêng.
+3. `package_telegram` tùy chọn gọi `NPM Telegram Beta E2E`. Nó chạy khi `telegram_mode` không phải `none` và cài đặt cùng artifact `package-under-test` khi Package Acceptance đã phân giải một gói; dispatch Telegram độc lập vẫn có thể cài đặt một thông số npm đã phát hành.
+4. `summary` làm workflow thất bại nếu phân giải gói, chấp nhận Docker, hoặc làn Telegram tùy chọn thất bại.
 
 ### Nguồn ứng viên
 
-- `source=npm` chỉ chấp nhận `openclaw@beta`, `openclaw@latest`, hoặc một phiên bản phát hành OpenClaw chính xác như `openclaw@2026.4.27-beta.2`. Dùng mục này cho quá trình chấp nhận beta/ổn định đã phát hành.
-- `source=ref` đóng gói một nhánh, thẻ, hoặc SHA commit đầy đủ `package_ref` đáng tin cậy. Bộ phân giải lấy các nhánh/thẻ OpenClaw, xác minh commit được chọn có thể truy ngược từ lịch sử nhánh kho lưu trữ hoặc thẻ phát hành, cài đặt phụ thuộc trong một worktree tách rời, rồi đóng gói bằng `scripts/package-openclaw-for-docker.mjs`.
-- `source=url` tải xuống một `.tgz` HTTPS; bắt buộc có `package_sha256`.
-- `source=artifact` tải xuống một `.tgz` từ `artifact_run_id` và `artifact_name`; `package_sha256` là tùy chọn nhưng nên được cung cấp cho các artifact được chia sẻ bên ngoài.
+- `source=npm` chỉ chấp nhận `openclaw@beta`, `openclaw@latest`, hoặc một phiên bản phát hành OpenClaw chính xác như `openclaw@2026.4.27-beta.2`. Dùng tùy chọn này cho việc chấp nhận bản beta/ổn định đã xuất bản.
+- `source=ref` đóng gói một nhánh, thẻ hoặc SHA commit đầy đủ đáng tin cậy của `package_ref`. Bộ phân giải tìm nạp các nhánh/thẻ OpenClaw, xác minh commit được chọn có thể truy cập từ lịch sử nhánh kho lưu trữ hoặc thẻ phát hành, cài đặt các phần phụ thuộc trong một worktree tách rời, rồi đóng gói bằng `scripts/package-openclaw-for-docker.mjs`.
+- `source=url` tải xuống một tệp HTTPS `.tgz`; bắt buộc phải có `package_sha256`.
+- `source=artifact` tải xuống một tệp `.tgz` từ `artifact_run_id` và `artifact_name`; `package_sha256` là tùy chọn nhưng nên được cung cấp cho các artifact được chia sẻ bên ngoài.
 
-Giữ `workflow_ref` và `package_ref` riêng biệt. `workflow_ref` là mã workflow/harness đáng tin cậy chạy bài kiểm thử. `package_ref` là commit nguồn được đóng gói khi `source=ref`. Điều này cho phép harness kiểm thử hiện tại xác thực các commit nguồn đáng tin cậy cũ hơn mà không chạy logic workflow cũ.
+Giữ `workflow_ref` và `package_ref` tách biệt. `workflow_ref` là mã workflow/harness đáng tin cậy chạy kiểm thử. `package_ref` là commit nguồn được đóng gói khi `source=ref`. Điều này cho phép harness kiểm thử hiện tại xác thực các commit nguồn đáng tin cậy cũ hơn mà không chạy logic workflow cũ.
 
 ### Hồ sơ bộ kiểm thử
 
 - `smoke` — `npm-onboard-channel-agent`, `gateway-network`, `config-reload`
-- `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `bundled-channel-deps-compat`, `plugins-offline`, `plugin-update`
-- `product` — `package` cộng với `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui`
-- `full` — các phần đường dẫn phát hành Docker đầy đủ với OpenWebUI
+- `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `upgrade-survivor`, `bundled-channel-deps-compat`, `plugins-offline`, `plugin-update`
+- `product` — `package` cộng thêm `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui`
+- `full` — các phần release-path Docker đầy đủ với OpenWebUI
 - `custom` — `docker_lanes` chính xác; bắt buộc khi `suite_profile=custom`
 
-Hồ sơ `package` dùng phạm vi phủ Plugin ngoại tuyến để quá trình xác thực gói đã phát hành không bị chặn bởi khả năng sẵn sàng trực tiếp của ClawHub. Lane Telegram tùy chọn dùng lại artifact `package-under-test` trong `NPM Telegram Beta E2E`, với đường dẫn spec npm đã phát hành được giữ cho các lần dispatch độc lập.
+Hồ sơ `package` dùng phạm vi kiểm thử Plugin ngoại tuyến để việc xác thực gói đã xuất bản không bị phụ thuộc vào tính khả dụng trực tiếp của ClawHub. Lane Telegram tùy chọn tái sử dụng artifact `package-under-test` trong `NPM Telegram Beta E2E`, với đường dẫn đặc tả npm đã xuất bản được giữ cho các lần dispatch độc lập.
 
-Kiểm tra phát hành gọi Package Acceptance với `source=ref`, `package_ref=<release-ref>`, `workflow_ref=<release workflow ref>`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'`, và `telegram_mode=mock-openai`. Các phần Docker đường dẫn phát hành bao phủ các lane package/update/plugin trùng lặp; Package Acceptance giữ bằng chứng compat kênh tích hợp sẵn theo artifact gốc, Plugin ngoại tuyến, và Telegram trên cùng tarball gói đã phân giải. Kiểm tra phát hành đa hệ điều hành vẫn bao phủ onboarding, trình cài đặt, và hành vi nền tảng đặc thù hệ điều hành; xác thực sản phẩm package/update nên bắt đầu bằng Package Acceptance. Các lane Windows packaged và installer fresh cũng xác minh rằng một gói đã cài đặt có thể import một browser-control override từ đường dẫn Windows tuyệt đối thô. Smoke agent-turn OpenAI đa hệ điều hành mặc định dùng `OPENCLAW_CROSS_OS_OPENAI_MODEL` khi được đặt, nếu không thì dùng `openai/gpt-5.4-mini`, để bằng chứng cài đặt và Gateway vẫn nhanh và xác định.
+Các kiểm tra phát hành gọi Package Acceptance với `source=ref`, `package_ref=<release-ref>`, `workflow_ref=<release workflow ref>`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'`, và `telegram_mode=mock-openai`. Các phần Docker release-path bao phủ các lane package/update/plugin chồng lắp; Package Acceptance giữ bằng chứng compat bundled-channel gốc theo artifact, Plugin ngoại tuyến và Telegram trên cùng tarball gói đã phân giải. Các kiểm tra phát hành cross-OS vẫn bao phủ hành vi onboarding, trình cài đặt và nền tảng dành riêng cho từng hệ điều hành; xác thực sản phẩm package/update nên bắt đầu với Package Acceptance. Các lane Windows packaged và installer fresh cũng xác minh rằng một gói đã cài đặt có thể import một override browser-control từ một đường dẫn Windows tuyệt đối thô. Smoke agent-turn cross-OS của OpenAI mặc định dùng `OPENCLAW_CROSS_OS_OPENAI_MODEL` khi được đặt, nếu không thì dùng `openai/gpt-5.4-mini`, để bằng chứng cài đặt và Gateway vẫn nhanh và xác định.
 
 ### Khoảng tương thích cũ
 
-Package Acceptance có các khoảng tương thích cũ có giới hạn cho những gói đã phát hành. Các gói đến hết `2026.4.25`, bao gồm `2026.4.25-beta.*`, có thể dùng đường dẫn tương thích:
+Package Acceptance có các khoảng tương thích cũ có giới hạn cho các gói đã được xuất bản. Các gói đến `2026.4.25`, bao gồm `2026.4.25-beta.*`, có thể dùng đường dẫn tương thích:
 
-- các mục QA riêng tư đã biết trong `dist/postinstall-inventory.json` có thể trỏ đến những tệp bị bỏ khỏi tarball;
-- `doctor-switch` có thể bỏ qua trường hợp con về tính bền vững `gateway install --wrapper` khi gói không cung cấp cờ đó;
-- `update-channel-switch` có thể lược bỏ `pnpm.patchedDependencies` bị thiếu khỏi fixture git giả bắt nguồn từ tarball và có thể ghi log `update.channel` đã lưu bền vững bị thiếu;
-- các smoke Plugin có thể đọc vị trí install-record cũ hoặc chấp nhận thiếu tính bền vững install-record của marketplace;
-- `plugin-update` có thể cho phép di trú siêu dữ liệu cấu hình trong khi vẫn yêu cầu install record và hành vi không cài đặt lại giữ nguyên.
+- các mục QA riêng tư đã biết trong `dist/postinstall-inventory.json` có thể trỏ đến các tệp bị lược khỏi tarball;
+- `doctor-switch` có thể bỏ qua subcase lưu bền `gateway install --wrapper` khi gói không cung cấp cờ đó;
+- `update-channel-switch` có thể cắt bỏ các `pnpm.patchedDependencies` bị thiếu khỏi fixture git giả được tạo từ tarball và có thể ghi log thiếu `update.channel` đã lưu bền;
+- các smoke Plugin có thể đọc các vị trí install-record cũ hoặc chấp nhận thiếu lưu bền install-record marketplace;
+- `plugin-update` có thể cho phép di chuyển siêu dữ liệu cấu hình trong khi vẫn yêu cầu install record và hành vi không cài đặt lại không đổi.
 
-Gói `2026.4.26` đã phát hành cũng có thể cảnh báo về các tệp dấu mốc siêu dữ liệu build cục bộ đã được phát hành. Các gói sau đó phải thỏa mãn các hợp đồng hiện đại; cùng những điều kiện đó sẽ thất bại thay vì cảnh báo hoặc bỏ qua.
+Gói `2026.4.26` đã xuất bản cũng có thể cảnh báo về các tệp dấu siêu dữ liệu bản dựng cục bộ đã được phát hành. Các gói về sau phải đáp ứng các hợp đồng hiện đại; cùng các điều kiện đó sẽ thất bại thay vì cảnh báo hoặc bỏ qua.
 
 ### Ví dụ
 
@@ -238,111 +238,111 @@ gh workflow run package-acceptance.yml \
   -f docker_lanes='install-e2e plugin-update'
 ```
 
-Khi gỡ lỗi một lần chạy chấp nhận gói thất bại, hãy bắt đầu từ phần tóm tắt `resolve_package` để xác nhận nguồn gói, phiên bản, và SHA-256. Sau đó kiểm tra lần chạy con `docker_acceptance` và các artifact Docker của nó: `.artifacts/docker-tests/**/summary.json`, `failures.json`, log lane, thời lượng pha, và lệnh chạy lại. Ưu tiên chạy lại hồ sơ gói thất bại hoặc các lane Docker chính xác thay vì chạy lại toàn bộ xác thực phát hành.
+Khi gỡ lỗi một lần chạy package acceptance thất bại, hãy bắt đầu từ phần tóm tắt `resolve_package` để xác nhận nguồn gói, phiên bản và SHA-256. Sau đó kiểm tra lần chạy con `docker_acceptance` và các artifact Docker của nó: `.artifacts/docker-tests/**/summary.json`, `failures.json`, log lane, thời gian từng pha và các lệnh chạy lại. Ưu tiên chạy lại hồ sơ gói thất bại hoặc các lane Docker chính xác thay vì chạy lại toàn bộ xác thực phát hành.
 
 ## Smoke cài đặt
 
-Workflow `Install Smoke` riêng biệt dùng lại cùng script phạm vi thông qua job `preflight` riêng của nó. Nó chia phạm vi smoke thành `run_fast_install_smoke` và `run_full_install_smoke`.
+Workflow `Install Smoke` riêng biệt tái sử dụng cùng script phạm vi thông qua job `preflight` riêng. Nó chia phạm vi smoke thành `run_fast_install_smoke` và `run_full_install_smoke`.
 
-- **Đường dẫn nhanh** chạy cho các pull request chạm tới bề mặt Docker/package, thay đổi gói/manifest Plugin tích hợp sẵn, hoặc các bề mặt core plugin/channel/gateway/Plugin SDK mà các job smoke Docker thực thi. Các thay đổi chỉ ở nguồn Plugin tích hợp sẵn, chỉnh sửa chỉ kiểm thử, và chỉnh sửa chỉ tài liệu không đặt trước worker Docker. Đường dẫn nhanh build image Dockerfile gốc một lần, kiểm tra CLI, chạy smoke CLI agents delete shared-workspace, chạy e2e gateway-network trong container, xác minh một build arg phần mở rộng tích hợp sẵn, và chạy hồ sơ Docker Plugin tích hợp sẵn có giới hạn dưới timeout lệnh tổng hợp 240 giây (mỗi lần chạy Docker của từng kịch bản được giới hạn riêng).
-- **Đường dẫn đầy đủ** giữ cài đặt gói QR và phạm vi Docker/update của trình cài đặt cho các lần chạy theo lịch hằng đêm, dispatch thủ công, kiểm tra phát hành workflow-call, và các pull request thực sự chạm tới bề mặt installer/package/Docker. Ở chế độ đầy đủ, install-smoke chuẩn bị hoặc dùng lại một image smoke Dockerfile gốc GHCR theo target-SHA, rồi chạy cài đặt gói QR, smoke Dockerfile/gateway gốc, smoke installer/update, và Docker E2E Plugin tích hợp sẵn nhanh dưới dạng các job riêng để công việc trình cài đặt không phải chờ sau các smoke image gốc.
+- **Đường dẫn nhanh** chạy cho pull request chạm đến các bề mặt Docker/package, thay đổi package/manifest của Plugin đi kèm, hoặc các bề mặt Plugin/kênh/Gateway/Plugin SDK lõi mà các job smoke Docker thực thi. Các thay đổi Plugin đi kèm chỉ ở nguồn, chỉnh sửa chỉ kiểm thử và chỉnh sửa chỉ tài liệu không giữ trước worker Docker. Đường dẫn nhanh dựng image Dockerfile gốc một lần, kiểm tra CLI, chạy smoke CLI agents delete shared-workspace, chạy e2e gateway-network trong container, xác minh build arg extension đi kèm, và chạy hồ sơ Docker bundled-plugin có giới hạn dưới timeout lệnh tổng hợp 240 giây (mỗi lần chạy Docker của từng kịch bản được giới hạn riêng).
+- **Đường dẫn đầy đủ** giữ phạm vi cài đặt package QR và Docker/update trình cài đặt cho các lần chạy lịch hằng đêm, dispatch thủ công, kiểm tra phát hành workflow-call và pull request thực sự chạm đến các bề mặt installer/package/Docker. Ở chế độ đầy đủ, install-smoke chuẩn bị hoặc tái sử dụng một image smoke Dockerfile gốc GHCR theo target-SHA, rồi chạy cài đặt package QR, smoke Dockerfile/gateway gốc, smoke installer/update và Docker E2E bundled-plugin nhanh dưới dạng các job riêng để công việc installer không phải chờ sau các smoke image gốc.
 
-Các push lên `main` (bao gồm merge commit) không ép buộc đường dẫn đầy đủ; khi logic phạm vi thay đổi yêu cầu phạm vi phủ đầy đủ trên một push, workflow giữ smoke Docker nhanh và để smoke cài đặt đầy đủ cho xác thực hằng đêm hoặc phát hành.
+Các lần push lên `main` (bao gồm merge commit) không bắt buộc đường dẫn đầy đủ; khi logic phạm vi thay đổi yêu cầu phạm vi đầy đủ trên một lần push, workflow giữ smoke Docker nhanh và để smoke cài đặt đầy đủ cho xác thực hằng đêm hoặc phát hành.
 
-Smoke image-provider cài đặt toàn cục Bun chậm được kiểm soát riêng bởi `run_bun_global_install_smoke`. Nó chạy theo lịch hằng đêm và từ workflow kiểm tra phát hành, và các dispatch `Install Smoke` thủ công có thể chọn bật nó, nhưng pull request và push lên `main` thì không. Các kiểm thử Docker QR và trình cài đặt giữ các Dockerfile tập trung vào cài đặt riêng của chúng.
+Smoke image-provider cài đặt toàn cục Bun chậm được kiểm soát riêng bằng `run_bun_global_install_smoke`. Nó chạy theo lịch hằng đêm và từ workflow kiểm tra phát hành, và các dispatch `Install Smoke` thủ công có thể chọn bật nó, nhưng pull request và các lần push lên `main` thì không. Các kiểm thử Docker QR và installer giữ các Dockerfile tập trung vào cài đặt của riêng chúng.
 
 ## Docker E2E cục bộ
 
-`pnpm test:docker:all` dựng sẵn một image live-test dùng chung, đóng gói OpenClaw một lần dưới dạng tarball npm, và build hai image `scripts/e2e/Dockerfile` dùng chung:
+`pnpm test:docker:all` dựng trước một image live-test dùng chung, đóng gói OpenClaw một lần dưới dạng tarball npm, và dựng hai image `scripts/e2e/Dockerfile` dùng chung:
 
 - một runner Node/Git tối giản cho các lane installer/update/plugin-dependency;
-- một image chức năng cài đặt cùng tarball đó vào `/app` cho các lane chức năng thông thường.
+- một image chức năng cài cùng tarball đó vào `/app` cho các lane chức năng thông thường.
 
-Định nghĩa lane Docker nằm trong `scripts/lib/docker-e2e-scenarios.mjs`, logic planner nằm trong `scripts/lib/docker-e2e-plan.mjs`, và runner chỉ thực thi kế hoạch đã chọn. Bộ lập lịch chọn image cho mỗi lane bằng `OPENCLAW_DOCKER_E2E_BARE_IMAGE` và `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, rồi chạy các lane với `OPENCLAW_SKIP_DOCKER_BUILD=1`.
+Định nghĩa lane Docker nằm trong `scripts/lib/docker-e2e-scenarios.mjs`, logic planner nằm trong `scripts/lib/docker-e2e-plan.mjs`, và runner chỉ thực thi plan đã chọn. Scheduler chọn image cho từng lane bằng `OPENCLAW_DOCKER_E2E_BARE_IMAGE` và `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, rồi chạy các lane với `OPENCLAW_SKIP_DOCKER_BUILD=1`.
 
 ### Tùy chỉnh
 
-| Biến                                   | Mặc định | Mục đích                                                                                      |
-| -------------------------------------- | -------- | --------------------------------------------------------------------------------------------- |
-| `OPENCLAW_DOCKER_ALL_PARALLELISM`      | 10       | Số slot nhóm chính cho các lane thông thường.                                                  |
-| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10       | Số slot nhóm đuôi nhạy với nhà cung cấp.                                                       |
-| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT`       | 9        | Giới hạn lane live đồng thời để các nhà cung cấp không điều tiết.                              |
-| `OPENCLAW_DOCKER_ALL_NPM_LIMIT`        | 10       | Giới hạn lane cài đặt npm đồng thời.                                                           |
-| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT`    | 7        | Giới hạn lane đa dịch vụ đồng thời.                                                            |
-| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000     | Độ giãn cách giữa các lần khởi động lane để tránh bão tạo Docker daemon; đặt `0` để không giãn cách. |
-| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`  | 7200000  | Timeout dự phòng cho mỗi lane (120 phút); các lane live/tail được chọn dùng giới hạn chặt hơn. |
-| `OPENCLAW_DOCKER_ALL_DRY_RUN`          | chưa đặt | `1` in kế hoạch bộ lập lịch mà không chạy lane.                                                |
-| `OPENCLAW_DOCKER_ALL_LANES`            | chưa đặt | Danh sách lane chính xác, phân tách bằng dấu phẩy; bỏ qua smoke dọn dẹp để agent có thể tái hiện một lane thất bại. |
+| Biến                                   | Mặc định | Mục đích                                                                                     |
+| -------------------------------------- | -------- | -------------------------------------------------------------------------------------------- |
+| `OPENCLAW_DOCKER_ALL_PARALLELISM`      | 10       | Số slot main-pool cho các lane thông thường.                                                 |
+| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10       | Số slot tail-pool nhạy cảm với provider.                                                     |
+| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT`       | 9        | Giới hạn lane live đồng thời để provider không throttle.                                     |
+| `OPENCLAW_DOCKER_ALL_NPM_LIMIT`        | 10       | Giới hạn lane cài đặt npm đồng thời.                                                         |
+| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT`    | 7        | Giới hạn lane đa dịch vụ đồng thời.                                                          |
+| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000     | Độ trễ giữa các lần bắt đầu lane để tránh bão tạo Docker daemon; đặt `0` để không tạo trễ.  |
+| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`  | 7200000  | Timeout dự phòng mỗi lane (120 phút); các lane live/tail được chọn dùng giới hạn chặt hơn.  |
+| `OPENCLAW_DOCKER_ALL_DRY_RUN`          | chưa đặt | `1` in plan scheduler mà không chạy lane.                                                    |
+| `OPENCLAW_DOCKER_ALL_LANES`            | chưa đặt | Danh sách lane chính xác phân tách bằng dấu phẩy; bỏ qua smoke dọn dẹp để agent có thể tái tạo một lane thất bại. |
 
-Một lane nặng hơn giới hạn hiệu dụng của nó vẫn có thể bắt đầu từ một nhóm trống, rồi chạy một mình cho đến khi giải phóng dung lượng. Tổng hợp cục bộ preflight Docker, xóa các container OpenClaw E2E cũ, phát trạng thái lane đang hoạt động, lưu thời lượng lane để sắp xếp dài nhất trước, và mặc định dừng lập lịch các lane trong nhóm mới sau lỗi đầu tiên.
+Một lane nặng hơn giới hạn hiệu dụng của nó vẫn có thể bắt đầu từ một pool trống, rồi chạy một mình cho đến khi nhả dung lượng. Tổng hợp cục bộ preflight Docker, xóa các container OpenClaw E2E cũ, phát trạng thái lane đang hoạt động, lưu bền thời gian lane để sắp xếp dài nhất trước, và mặc định dừng lên lịch các lane pooled mới sau lỗi đầu tiên.
 
 ### Workflow live/E2E tái sử dụng
 
-Workflow live/E2E tái sử dụng hỏi `scripts/test-docker-all.mjs --plan-json` xem cần gói, loại image, image live, lane, và phạm vi thông tin xác thực nào. Sau đó `scripts/docker-e2e.mjs` chuyển kế hoạch đó thành GitHub outputs và tóm tắt. Nó hoặc đóng gói OpenClaw thông qua `scripts/package-openclaw-for-docker.mjs`, tải xuống artifact gói của lần chạy hiện tại, hoặc tải xuống artifact gói từ `package_artifact_run_id`; xác thực inventory tarball; build và push image Docker E2E bare/functional GHCR được gắn thẻ theo digest gói thông qua cache lớp Docker của Blacksmith khi kế hoạch cần các lane đã cài gói; và dùng lại các input `docker_e2e_bare_image`/`docker_e2e_functional_image` đã cung cấp hoặc các image theo digest gói hiện có thay vì build lại. Các lần pull image Docker được thử lại với timeout mỗi lần thử có giới hạn 180 giây để một luồng registry/cache bị kẹt được thử lại nhanh chóng thay vì tiêu tốn phần lớn đường găng CI.
+Workflow live/E2E tái sử dụng hỏi `scripts/test-docker-all.mjs --plan-json` xem cần phạm vi package, loại image, image live, lane và credential nào. Sau đó `scripts/docker-e2e.mjs` chuyển plan đó thành output và tóm tắt GitHub. Nó hoặc đóng gói OpenClaw thông qua `scripts/package-openclaw-for-docker.mjs`, tải xuống artifact package của lần chạy hiện tại, hoặc tải xuống artifact package từ `package_artifact_run_id`; xác thực inventory tarball; dựng và push các image Docker E2E bare/functional GHCR được gắn thẻ theo package-digest thông qua cache lớp Docker của Blacksmith khi plan cần các lane đã cài package; và tái sử dụng input `docker_e2e_bare_image`/`docker_e2e_functional_image` được cung cấp hoặc các image package-digest hiện có thay vì dựng lại. Các lần pull image Docker được thử lại với timeout mỗi lần thử có giới hạn 180 giây để một luồng registry/cache bị kẹt sẽ thử lại nhanh thay vì tiêu thụ phần lớn đường găng CI.
 
-### Các phần đường dẫn phát hành
+### Các phần release-path
 
-Phạm vi Docker phát hành chạy các job nhỏ hơn theo từng phần với `OPENCLAW_SKIP_DOCKER_BUILD=1` để mỗi phần chỉ pull loại image nó cần và thực thi nhiều lane thông qua cùng bộ lập lịch có trọng số:
+Phạm vi Docker phát hành chạy các job chia nhỏ hơn với `OPENCLAW_SKIP_DOCKER_BUILD=1` để mỗi phần chỉ pull loại image nó cần và thực thi nhiều lane thông qua cùng scheduler có trọng số:
 
 - `OPENCLAW_DOCKER_ALL_PROFILE=release-path`
 - `OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h | bundled-channels`
 
-Các khối Docker của bản phát hành hiện tại là `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, `plugins-runtime-install-a` đến `plugins-runtime-install-h`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b`, và `bundled-channels-contracts`. Khối tổng hợp `bundled-channels` vẫn khả dụng cho các lần chạy lại thủ công một lần, còn `plugins-runtime-core`, `plugins-runtime`, và `plugins-integrations` vẫn là các bí danh plugin/runtime tổng hợp. Bí danh làn `install-e2e` vẫn là bí danh chạy lại thủ công tổng hợp cho cả hai làn trình cài đặt nhà cung cấp. Khối `bundled-channels` chạy các làn tách `bundled-channel-*` và `bundled-channel-update-*` thay vì làn tuần tự tất cả trong một `bundled-channel-deps`.
+Các chunk Docker của bản phát hành hiện tại là `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, `plugins-runtime-install-a` đến `plugins-runtime-install-h`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b`, và `bundled-channels-contracts`. Chunk tổng hợp `bundled-channels` vẫn khả dụng cho các lần chạy lại thủ công một lần, và `plugins-runtime-core`, `plugins-runtime`, cùng `plugins-integrations` vẫn là các bí danh Plugin/runtime tổng hợp. Bí danh lane `install-e2e` vẫn là bí danh chạy lại thủ công tổng hợp cho cả hai lane trình cài đặt provider. Chunk `bundled-channels` chạy các lane `bundled-channel-*` và `bundled-channel-update-*` đã tách, thay vì lane `bundled-channel-deps` nối tiếp gộp tất cả trong một.
 
-OpenWebUI được gộp vào `plugins-runtime-services` khi phạm vi phủ đường dẫn phát hành đầy đủ yêu cầu, và chỉ giữ một khối độc lập `openwebui` cho các lượt dispatch chỉ dành cho OpenWebUI. Các làn cập nhật kênh đi kèm thử lại một lần đối với lỗi mạng npm tạm thời.
+OpenWebUI được gộp vào `plugins-runtime-services` khi phạm vi bao phủ đường dẫn phát hành đầy đủ yêu cầu, và chỉ giữ chunk độc lập `openwebui` cho các dispatch chỉ dành cho OpenWebUI. Các lane cập nhật kênh đi kèm thử lại một lần đối với lỗi mạng npm nhất thời.
 
-Mỗi khối tải lên `.artifacts/docker-tests/` với nhật ký làn, thời gian chạy, `summary.json`, `failures.json`, thời gian từng pha, JSON kế hoạch của bộ lập lịch, bảng làn chậm, và các lệnh chạy lại theo từng làn. Đầu vào `docker_lanes` của workflow chạy các làn đã chọn trên các image đã chuẩn bị thay vì các job khối, giúp việc gỡ lỗi làn thất bại được giới hạn trong một job Docker có mục tiêu và chuẩn bị, tải xuống, hoặc tái sử dụng artifact gói cho lần chạy đó; nếu một làn được chọn là làn Docker live, job có mục tiêu sẽ build image kiểm thử live cục bộ cho lần chạy lại đó. Các lệnh chạy lại GitHub được tạo theo từng làn bao gồm `package_artifact_run_id`, `package_artifact_name`, và các đầu vào image đã chuẩn bị khi những giá trị đó tồn tại, để một làn thất bại có thể tái sử dụng đúng gói và image từ lần chạy thất bại.
+Mỗi chunk tải lên `.artifacts/docker-tests/` cùng với nhật ký lane, thời gian chạy, `summary.json`, `failures.json`, thời gian từng pha, JSON kế hoạch bộ lập lịch, bảng lane chậm, và lệnh chạy lại cho từng lane. Input `docker_lanes` của workflow chạy các lane đã chọn trên các image đã chuẩn bị thay vì các job chunk, nhờ đó việc gỡ lỗi lane lỗi được giới hạn trong một job Docker mục tiêu và chuẩn bị, tải xuống, hoặc tái sử dụng artifact gói cho lần chạy đó; nếu một lane đã chọn là lane Docker live, job mục tiêu sẽ build image kiểm thử live cục bộ cho lần chạy lại đó. Các lệnh chạy lại GitHub được tạo cho từng lane bao gồm `package_artifact_run_id`, `package_artifact_name`, và các input image đã chuẩn bị khi những giá trị đó tồn tại, để một lane lỗi có thể tái sử dụng đúng gói và image từ lần chạy lỗi.
 
 ```bash
-pnpm test:docker:rerun <run-id>      # tải xuống artifact Docker và in các lệnh chạy lại có mục tiêu dạng kết hợp/theo từng làn
-pnpm test:docker:timings <summary>   # tóm tắt làn chậm và đường găng theo pha
+pnpm test:docker:rerun <run-id>      # download Docker artifacts and print combined/per-lane targeted rerun commands
+pnpm test:docker:timings <summary>   # slow-lane and phase critical-path summaries
 ```
 
-Workflow live/E2E theo lịch chạy toàn bộ bộ Docker đường dẫn phát hành hằng ngày.
+Workflow live/E2E theo lịch chạy bộ kiểm thử Docker đầy đủ của đường dẫn phát hành hằng ngày.
 
 ## Bản phát hành trước Plugin
 
-`Plugin Prerelease` là phạm vi phủ sản phẩm/gói tốn kém hơn, nên đây là workflow riêng được dispatch bởi `Full Release Validation` hoặc bởi một người vận hành rõ ràng. Các pull request thông thường, lượt push lên `main`, và các lượt dispatch CI thủ công độc lập không bật bộ này. Nó cân bằng các bài kiểm thử plugin đi kèm trên tám worker tiện ích mở rộng; các job shard tiện ích mở rộng đó chạy tối đa hai nhóm cấu hình plugin cùng lúc với một worker Vitest cho mỗi nhóm và heap Node lớn hơn để các lô plugin nặng về import không tạo thêm job CI.
+`Plugin Prerelease` có phạm vi bao phủ sản phẩm/gói tốn kém hơn, nên đây là một workflow riêng được dispatch bởi `Full Release Validation` hoặc bởi một operator rõ ràng. Các pull request thông thường, push lên `main`, và dispatch CI thủ công độc lập không chạy bộ kiểm thử đó. Workflow này cân bằng các kiểm thử Plugin đi kèm trên tám worker extension; các job shard extension đó chạy tối đa hai nhóm cấu hình Plugin cùng lúc, với một worker Vitest cho mỗi nhóm và heap Node lớn hơn để các batch Plugin nặng về import không tạo thêm job CI.
 
-## QA Lab
+## Phòng kiểm thử QA
 
-QA Lab có các làn CI chuyên dụng nằm ngoài workflow chính có phạm vi thông minh.
+Phòng kiểm thử QA có các lane CI riêng nằm ngoài workflow scoped thông minh chính.
 
-- Workflow `Parity gate` chạy trên các thay đổi PR khớp và dispatch thủ công; nó build runtime QA riêng tư và so sánh các gói agentic GPT-5.5 và Opus 4.6 giả lập.
-- Workflow `QA-Lab - All Lanes` chạy hằng đêm trên `main` và khi dispatch thủ công; nó tỏa ra cổng parity giả lập, làn Matrix live, và các làn Telegram và Discord live dưới dạng các job song song. Các job live dùng môi trường `qa-live-shared`, còn Telegram/Discord dùng lease Convex.
+- Workflow `Parity gate` chạy trên các thay đổi PR khớp điều kiện và dispatch thủ công; nó build runtime QA riêng và so sánh các pack agentic GPT-5.5 và Opus 4.6 mô phỏng.
+- Workflow `QA-Lab - All Lanes` chạy hằng đêm trên `main` và khi dispatch thủ công; nó phân tán cổng parity mô phỏng, lane Matrix live, và các lane Telegram cùng Discord live thành các job song song. Các job live dùng môi trường `qa-live-shared`, còn Telegram/Discord dùng lease Convex.
 
-Các kiểm tra phát hành chạy các làn truyền tải Matrix và Telegram live với nhà cung cấp giả lập xác định và các model đủ điều kiện giả lập (`mock-openai/gpt-5.5` và `mock-openai/gpt-5.5-alt`) để hợp đồng kênh được cô lập khỏi độ trễ model live và khởi động plugin nhà cung cấp thông thường. Gateway truyền tải live tắt tìm kiếm bộ nhớ vì QA parity bao phủ riêng hành vi bộ nhớ; kết nối nhà cung cấp được bao phủ bởi các bộ model live, nhà cung cấp native, và nhà cung cấp Docker riêng biệt.
+Các kiểm tra phát hành chạy các lane vận chuyển live Matrix và Telegram với provider mô phỏng xác định và các model đủ điều kiện mô phỏng (`mock-openai/gpt-5.5` và `mock-openai/gpt-5.5-alt`) để hợp đồng kênh được tách biệt khỏi độ trễ model live và quá trình khởi động Plugin provider thông thường. Gateway vận chuyển live tắt tìm kiếm bộ nhớ vì parity QA bao phủ riêng hành vi bộ nhớ; khả năng kết nối provider được bao phủ bởi các bộ kiểm thử riêng cho model live, provider native, và provider Docker.
 
-Matrix dùng `--profile fast` cho các cổng theo lịch và phát hành, chỉ thêm `--fail-fast` khi CLI đã checkout hỗ trợ nó. Mặc định CLI và đầu vào workflow thủ công vẫn là `all`; dispatch thủ công `matrix_profile=all` luôn chia nhỏ phạm vi phủ Matrix đầy đủ thành các job `transport`, `media`, `e2ee-smoke`, `e2ee-deep`, và `e2ee-cli`.
+Matrix dùng `--profile fast` cho các cổng theo lịch và phát hành, chỉ thêm `--fail-fast` khi CLI đã checkout hỗ trợ. Mặc định CLI và input workflow thủ công vẫn là `all`; dispatch thủ công `matrix_profile=all` luôn shard phạm vi bao phủ Matrix đầy đủ thành các job `transport`, `media`, `e2ee-smoke`, `e2ee-deep`, và `e2ee-cli`.
 
-`OpenClaw Release Checks` cũng chạy các làn QA Lab trọng yếu cho phát hành trước khi phê duyệt phát hành; cổng QA parity của nó chạy các gói ứng viên và baseline dưới dạng các job làn song song, rồi tải xuống cả hai artifact vào một job báo cáo nhỏ cho phép so sánh parity cuối cùng.
+`OpenClaw Release Checks` cũng chạy các lane QA Lab quan trọng cho phát hành trước khi phê duyệt phát hành; cổng parity QA của nó chạy các pack ứng viên và baseline dưới dạng job lane song song, rồi tải cả hai artifact xuống một job báo cáo nhỏ để so sánh parity cuối cùng.
 
-Không đặt đường dẫn landing PR sau `Parity gate` trừ khi thay đổi thực sự chạm tới runtime QA, parity gói model, hoặc một bề mặt do workflow parity sở hữu. Với các bản sửa kênh, cấu hình, tài liệu, hoặc kiểm thử đơn vị thông thường, hãy xem đó là tín hiệu tùy chọn và đi theo bằng chứng CI/kiểm tra có phạm vi.
+Không đặt đường dẫn landing PR phía sau `Parity gate` trừ khi thay đổi thực sự chạm đến runtime QA, parity model-pack, hoặc một bề mặt do workflow parity sở hữu. Với các bản sửa kênh, cấu hình, tài liệu, hoặc kiểm thử đơn vị thông thường, hãy xem đó là tín hiệu tùy chọn và làm theo bằng chứng CI/kiểm tra theo phạm vi.
 
 ## CodeQL
 
-Workflow `CodeQL` cố ý là trình quét bảo mật lượt đầu có phạm vi hẹp, không phải quét toàn bộ kho lưu trữ. Các lần chạy bảo vệ hằng ngày, thủ công, và pull request không phải draft quét mã workflow Actions cùng các bề mặt JavaScript/TypeScript rủi ro cao nhất bằng các truy vấn bảo mật độ tin cậy cao được lọc theo `security-severity` cao/nghiêm trọng.
+Workflow `CodeQL` cố ý là trình quét bảo mật lượt đầu phạm vi hẹp, không phải quét toàn bộ repository. Các lần chạy hằng ngày, thủ công, và bảo vệ pull request không phải draft quét mã workflow Actions cùng các bề mặt JavaScript/TypeScript rủi ro cao nhất bằng các truy vấn bảo mật độ tin cậy cao được lọc theo `security-severity` cao/nghiêm trọng.
 
-Bảo vệ pull request vẫn nhẹ: nó chỉ khởi động cho các thay đổi dưới `.github/actions`, `.github/codeql`, `.github/workflows`, `packages`, hoặc `src`, và chạy cùng ma trận bảo mật độ tin cậy cao như workflow theo lịch. CodeQL Android và macOS không nằm trong mặc định PR.
+Bảo vệ pull request vẫn nhẹ: nó chỉ bắt đầu với các thay đổi dưới `.github/actions`, `.github/codeql`, `.github/workflows`, `packages`, hoặc `src`, và chạy cùng ma trận bảo mật độ tin cậy cao như workflow theo lịch. CodeQL Android và macOS không nằm trong mặc định PR.
 
 ### Danh mục bảo mật
 
 | Danh mục                                          | Bề mặt                                                                                                                                |
 | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
-| `/codeql-security-high/core-auth-secrets`         | Xác thực, secret, sandbox, cron, và baseline gateway                                                                                     |
-| `/codeql-security-high/channel-runtime-boundary`  | Hợp đồng triển khai kênh lõi cùng runtime plugin kênh, Gateway, Plugin SDK, secret, các điểm chạm kiểm toán                 |
-| `/codeql-security-high/network-ssrf-boundary`     | Các bề mặt SSRF lõi, phân tích IP, bảo vệ mạng, web-fetch, và chính sách SSRF của Plugin SDK                                                   |
-| `/codeql-security-high/mcp-process-tool-boundary` | Máy chủ MCP, helper thực thi tiến trình, phân phối gửi ra ngoài, và cổng thực thi công cụ của agent                                              |
-| `/codeql-security-high/plugin-trust-boundary`     | Các bề mặt tin cậy của cài đặt Plugin, loader, manifest, registry, staging phụ thuộc runtime, tải nguồn, và hợp đồng gói Plugin SDK |
+| `/codeql-security-high/core-auth-secrets`         | Auth, secret, sandbox, cron, và baseline Gateway                                                                                     |
+| `/codeql-security-high/channel-runtime-boundary`  | Các hợp đồng triển khai kênh lõi cộng với runtime Plugin kênh, Gateway, Plugin SDK, secret, điểm chạm audit                 |
+| `/codeql-security-high/network-ssrf-boundary`     | Các bề mặt SSRF lõi, phân tích IP, bảo vệ mạng, web-fetch, và chính sách SSRF Plugin SDK                                                   |
+| `/codeql-security-high/mcp-process-tool-boundary` | Máy chủ MCP, helper thực thi tiến trình, gửi outbound, và cổng thực thi công cụ agent                                              |
+| `/codeql-security-high/plugin-trust-boundary`     | Các bề mặt tin cậy của cài đặt Plugin, loader, manifest, registry, staging dependency runtime, tải nguồn, và hợp đồng gói Plugin SDK |
 
 ### Shard bảo mật theo nền tảng
 
 - `CodeQL Android Critical Security` — shard bảo mật Android theo lịch. Build ứng dụng Android thủ công cho CodeQL trên runner Blacksmith Linux nhỏ nhất được workflow sanity chấp nhận. Tải lên dưới `/codeql-critical-security/android`.
-- `CodeQL macOS Critical Security` — shard bảo mật macOS hằng tuần/thủ công. Build ứng dụng macOS thủ công cho CodeQL trên Blacksmith macOS, lọc kết quả build phụ thuộc khỏi SARIF được tải lên, và tải lên dưới `/codeql-critical-security/macos`. Được giữ ngoài mặc định hằng ngày vì build macOS chiếm phần lớn thời gian chạy ngay cả khi sạch.
+- `CodeQL macOS Critical Security` — shard bảo mật macOS hằng tuần/thủ công. Build ứng dụng macOS thủ công cho CodeQL trên Blacksmith macOS, lọc kết quả build dependency ra khỏi SARIF đã tải lên, và tải lên dưới `/codeql-critical-security/macos`. Được giữ ngoài mặc định hằng ngày vì build macOS chiếm phần lớn thời gian chạy ngay cả khi sạch.
 
 ### Danh mục Chất lượng Nghiêm trọng
 
-`CodeQL Critical Quality` là shard không liên quan đến bảo mật tương ứng. Nó chỉ chạy các truy vấn chất lượng JavaScript/TypeScript không bảo mật, mức độ lỗi, trên các bề mặt hẹp có giá trị cao trên runner Blacksmith Linux nhỏ hơn. Bảo vệ pull request của nó cố ý nhỏ hơn profile theo lịch: các PR không phải draft chỉ chạy các shard `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract`, và `plugin-sdk-reply-runtime` tương ứng cho mã thực thi lệnh/model/công cụ của agent và dispatch phản hồi, mã schema/cấu hình/di trú/IO, mã auth/secret/sandbox/bảo mật, runtime kênh lõi và plugin kênh đi kèm, giao thức Gateway/phương thức máy chủ, runtime bộ nhớ/glue SDK, MCP/tiến trình/phân phối gửi ra ngoài, runtime nhà cung cấp/danh mục model, chẩn đoán phiên/hàng đợi phân phối, loader plugin, hợp đồng Plugin SDK/gói, hoặc thay đổi runtime phản hồi Plugin SDK. Các thay đổi cấu hình CodeQL và workflow chất lượng chạy cả mười hai shard chất lượng PR.
+`CodeQL Critical Quality` là shard phi bảo mật tương ứng. Nó chỉ chạy các truy vấn chất lượng JavaScript/TypeScript không phải bảo mật, mức nghiêm trọng lỗi, trên các bề mặt giá trị cao phạm vi hẹp trên runner Blacksmith Linux nhỏ hơn. Bảo vệ pull request của nó cố ý nhỏ hơn profile theo lịch: PR không phải draft chỉ chạy các shard `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract`, và `plugin-sdk-reply-runtime` tương ứng cho các thay đổi trong mã thực thi lệnh/model/công cụ agent và dispatch phản hồi, mã schema/cấu hình/migration/IO, mã auth/secret/sandbox/bảo mật, runtime Plugin kênh lõi và kênh đi kèm, protocol Gateway/server-method, runtime bộ nhớ/liên kết SDK, MCP/tiến trình/gửi outbound, runtime provider/catalog model, chẩn đoán phiên/hàng đợi gửi, loader Plugin, hợp đồng Plugin SDK/gói, hoặc runtime phản hồi Plugin SDK. Các thay đổi cấu hình CodeQL và workflow chất lượng chạy toàn bộ mười hai shard chất lượng PR.
 
 Dispatch thủ công chấp nhận:
 
@@ -350,40 +350,40 @@ Dispatch thủ công chấp nhận:
 profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary
 ```
 
-Các profile hẹp là các hook hướng dẫn/lặp để chạy một shard chất lượng riêng lẻ.
+Các profile hẹp là hook hướng dẫn/lặp để chạy một shard chất lượng riêng lẻ.
 
-| Danh mục                                                | Bề mặt                                                                                                                                                           |
-| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `/codeql-critical-quality/core-auth-secrets`            | Mã ranh giới bảo mật cho xác thực, bí mật, sandbox, Cron và Gateway                                                                                                  |
-| `/codeql-critical-quality/config-boundary`              | Hợp đồng về lược đồ cấu hình, di chuyển, chuẩn hóa và IO                                                                                                         |
-| `/codeql-critical-quality/gateway-runtime-boundary`     | Lược đồ giao thức Gateway và hợp đồng phương thức máy chủ                                                                                                              |
-| `/codeql-critical-quality/channel-runtime-boundary`     | Hợp đồng triển khai kênh lõi và Plugin kênh đi kèm                                                                                                  |
-| `/codeql-critical-quality/agent-runtime-boundary`       | Hợp đồng runtime cho thực thi lệnh, điều phối model/provider, điều phối và hàng đợi tự động trả lời, cùng control plane ACP                                               |
-| `/codeql-critical-quality/mcp-process-runtime-boundary` | Máy chủ MCP và cầu nối công cụ, helper giám sát tiến trình, và hợp đồng gửi đi                                                                        |
-| `/codeql-critical-quality/memory-runtime-boundary`      | SDK máy chủ bộ nhớ, facade runtime bộ nhớ, bí danh SDK Plugin bộ nhớ, phần nối kích hoạt runtime bộ nhớ, và lệnh doctor bộ nhớ                                    |
-| `/codeql-critical-quality/session-diagnostics-boundary` | Nội bộ hàng đợi trả lời, hàng đợi gửi phiên, helper liên kết/gửi phiên ra ngoài, bề mặt gói sự kiện/nhật ký chẩn đoán, và hợp đồng CLI doctor phiên |
-| `/codeql-critical-quality/plugin-sdk-reply-runtime`     | Điều phối trả lời đến SDK Plugin, helper payload/chunking/runtime cho trả lời, tùy chọn trả lời kênh, hàng đợi gửi, và helper liên kết phiên/luồng             |
-| `/codeql-critical-quality/provider-runtime-boundary`    | Chuẩn hóa danh mục model, xác thực và khám phá provider, đăng ký runtime provider, mặc định/danh mục provider, và registry web/search/fetch/embedding    |
-| `/codeql-critical-quality/ui-control-plane`             | Bootstrap giao diện điều khiển, lưu trữ cục bộ, luồng điều khiển Gateway, và hợp đồng runtime control plane tác vụ                                                          |
-| `/codeql-critical-quality/web-media-runtime-boundary`   | Hợp đồng runtime cho web fetch/search lõi, IO media, hiểu media, tạo hình ảnh, và tạo media                                                    |
-| `/codeql-critical-quality/plugin-boundary`              | Hợp đồng loader, registry, bề mặt công khai, và entrypoint SDK Plugin                                                                                             |
-| `/codeql-critical-quality/plugin-sdk-package-contract`  | Mã nguồn SDK Plugin phía gói đã phát hành và helper hợp đồng gói plugin                                                                                      |
+| Danh mục                                                | Bề mặt                                                                                                                                                                           |
+| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `/codeql-critical-quality/core-auth-secrets`            | Mã ranh giới bảo mật cho xác thực, bí mật, sandbox, Cron và Gateway                                                                                                             |
+| `/codeql-critical-quality/config-boundary`              | Hợp đồng lược đồ cấu hình, di trú, chuẩn hóa và IO                                                                                                                              |
+| `/codeql-critical-quality/gateway-runtime-boundary`     | Lược đồ giao thức Gateway và hợp đồng phương thức máy chủ                                                                                                                       |
+| `/codeql-critical-quality/channel-runtime-boundary`     | Hợp đồng triển khai kênh lõi và Plugin kênh đi kèm                                                                                                                             |
+| `/codeql-critical-quality/agent-runtime-boundary`       | Hợp đồng runtime cho thực thi lệnh, điều phối model/provider, điều phối và hàng đợi tự động trả lời, và mặt phẳng điều khiển ACP                                                |
+| `/codeql-critical-quality/mcp-process-runtime-boundary` | Máy chủ MCP và cầu nối công cụ, helper giám sát tiến trình, và hợp đồng gửi đi                                                                                                  |
+| `/codeql-critical-quality/memory-runtime-boundary`      | Memory host SDK, facade runtime bộ nhớ, bí danh Plugin SDK bộ nhớ, phần gắn kích hoạt runtime bộ nhớ, và lệnh doctor bộ nhớ                                                     |
+| `/codeql-critical-quality/session-diagnostics-boundary` | Nội bộ hàng đợi trả lời, hàng đợi gửi phiên, helper liên kết/gửi phiên đi, bề mặt gói sự kiện/nhật ký chẩn đoán, và hợp đồng CLI doctor phiên                                  |
+| `/codeql-critical-quality/plugin-sdk-reply-runtime`     | Điều phối trả lời đầu vào Plugin SDK, helper payload/chia khúc/runtime trả lời, tùy chọn trả lời kênh, hàng đợi gửi, và helper liên kết phiên/luồng                             |
+| `/codeql-critical-quality/provider-runtime-boundary`    | Chuẩn hóa danh mục model, xác thực và khám phá provider, đăng ký runtime provider, mặc định/danh mục provider, và registry web/search/fetch/embedding                           |
+| `/codeql-critical-quality/ui-control-plane`             | Khởi động Control UI, lưu trữ cục bộ, luồng điều khiển Gateway, và hợp đồng runtime mặt phẳng điều khiển tác vụ                                                                 |
+| `/codeql-critical-quality/web-media-runtime-boundary`   | Hợp đồng runtime cho web fetch/search lõi, media IO, hiểu media, tạo ảnh, và tạo media                                                                                          |
+| `/codeql-critical-quality/plugin-boundary`              | Hợp đồng loader, registry, bề mặt công khai, và điểm vào Plugin SDK                                                                                                             |
+| `/codeql-critical-quality/plugin-sdk-package-contract`  | Mã nguồn Plugin SDK phía gói đã xuất bản và helper hợp đồng gói Plugin                                                                                                          |
 
-Chất lượng được tách riêng khỏi bảo mật để các phát hiện về chất lượng có thể được lên lịch, đo lường, vô hiệu hóa hoặc mở rộng mà không che khuất tín hiệu bảo mật. Việc mở rộng CodeQL cho Swift, Python và Plugin đi kèm chỉ nên được thêm lại dưới dạng công việc tiếp nối có phạm vi hoặc được chia mảnh sau khi các hồ sơ hẹp đã có runtime và tín hiệu ổn định.
+Chất lượng được tách riêng khỏi bảo mật để các phát hiện về chất lượng có thể được lên lịch, đo lường, vô hiệu hóa hoặc mở rộng mà không che khuất tín hiệu bảo mật. Việc mở rộng CodeQL cho Swift, Python và Plugin đi kèm chỉ nên được thêm lại dưới dạng công việc tiếp theo có phạm vi hoặc được chia shard sau khi các hồ sơ hẹp có runtime và tín hiệu ổn định.
 
 ## Quy trình bảo trì
 
 ### Docs Agent
 
-Quy trình `Docs Agent` là một làn bảo trì Codex theo sự kiện để giữ tài liệu hiện có đồng bộ với các thay đổi vừa được merge. Nó không có lịch thuần túy: một lượt chạy CI push không phải bot thành công trên `main` có thể kích hoạt nó, và dispatch thủ công có thể chạy trực tiếp. Các lần gọi workflow-run sẽ bỏ qua khi `main` đã tiến lên hoặc khi một lượt chạy Docs Agent không bị bỏ qua khác đã được tạo trong giờ trước đó. Khi chạy, nó xem xét dải commit từ SHA nguồn Docs Agent không bị bỏ qua trước đó đến `main` hiện tại, vì vậy một lượt chạy hằng giờ có thể bao phủ mọi thay đổi trên main đã tích lũy kể từ lần rà soát tài liệu gần nhất.
+Quy trình `Docs Agent` là một lane bảo trì Codex theo sự kiện để giữ tài liệu hiện có đồng bộ với các thay đổi vừa được merge. Nó không có lịch chạy thuần túy: một lượt chạy CI push không phải bot thành công trên `main` có thể kích hoạt nó, và thao tác dispatch thủ công có thể chạy trực tiếp. Các lượt gọi workflow-run sẽ bỏ qua khi `main` đã tiến lên hoặc khi một lượt chạy Docs Agent không bị bỏ qua khác đã được tạo trong giờ vừa qua. Khi chạy, nó xem xét phạm vi commit từ SHA nguồn Docs Agent không bị bỏ qua trước đó đến `main` hiện tại, nên một lượt chạy mỗi giờ có thể bao phủ toàn bộ thay đổi trên main tích lũy kể từ lượt rà soát tài liệu gần nhất.
 
 ### Test Performance Agent
 
-Quy trình `Test Performance Agent` là một làn bảo trì Codex theo sự kiện dành cho các bài kiểm thử chậm. Nó không có lịch thuần túy: một lượt chạy CI push không phải bot thành công trên `main` có thể kích hoạt nó, nhưng nó sẽ bỏ qua nếu một lần gọi workflow-run khác đã chạy hoặc đang chạy trong ngày UTC đó. Dispatch thủ công bỏ qua cổng hoạt động hằng ngày này. Làn này tạo báo cáo hiệu năng Vitest toàn bộ bộ kiểm thử theo nhóm, cho phép Codex chỉ thực hiện các bản sửa hiệu năng kiểm thử nhỏ vẫn giữ nguyên độ bao phủ thay vì refactor rộng, rồi chạy lại báo cáo toàn bộ bộ kiểm thử và từ chối các thay đổi làm giảm số lượng bài kiểm thử baseline đang pass. Nếu baseline có bài kiểm thử thất bại, Codex chỉ được sửa các lỗi rõ ràng và báo cáo toàn bộ bộ kiểm thử sau agent phải pass trước khi bất cứ thứ gì được commit. Khi `main` tiến lên trước khi bot push được merge, làn này rebase bản vá đã xác thực, chạy lại `pnpm check:changed`, và thử push lại; các bản vá cũ có xung đột sẽ bị bỏ qua. Nó dùng Ubuntu do GitHub-hosted cung cấp để action Codex có thể giữ cùng tư thế an toàn drop-sudo như docs agent.
+Quy trình `Test Performance Agent` là một lane bảo trì Codex theo sự kiện dành cho các kiểm thử chậm. Nó không có lịch chạy thuần túy: một lượt chạy CI push không phải bot thành công trên `main` có thể kích hoạt nó, nhưng nó sẽ bỏ qua nếu một lượt gọi workflow-run khác đã chạy hoặc đang chạy trong cùng ngày UTC đó. Dispatch thủ công bỏ qua cổng hoạt động hằng ngày này. Lane tạo báo cáo hiệu năng Vitest toàn bộ bộ kiểm thử theo nhóm, cho phép Codex chỉ thực hiện các sửa đổi hiệu năng kiểm thử nhỏ vẫn giữ nguyên coverage thay vì refactor rộng, sau đó chạy lại báo cáo toàn bộ bộ kiểm thử và từ chối các thay đổi làm giảm số lượng kiểm thử baseline đang pass. Nếu baseline có kiểm thử đang fail, Codex chỉ có thể sửa các lỗi hiển nhiên và báo cáo toàn bộ bộ kiểm thử sau-agent phải pass trước khi bất kỳ thứ gì được commit. Khi `main` tiến lên trước khi lượt push của bot được đưa lên, lane rebase bản vá đã xác thực, chạy lại `pnpm check:changed`, và thử push lại; các bản vá cũ xung đột sẽ bị bỏ qua. Nó dùng Ubuntu do GitHub host để action Codex có thể giữ cùng tư thế an toàn drop-sudo như docs agent.
 
 ### PR trùng lặp sau khi merge
 
-Quy trình `Duplicate PRs After Merge` là một quy trình maintainer thủ công để dọn dẹp trùng lặp sau khi merge. Mặc định là dry-run và chỉ đóng các PR được liệt kê rõ ràng khi `apply=true`. Trước khi thay đổi GitHub, nó xác minh rằng PR đã landed đã được merge và mỗi bản trùng lặp có issue được tham chiếu chung hoặc các hunk thay đổi chồng lấn.
+Quy trình `Duplicate PRs After Merge` là quy trình maintainer thủ công để dọn dẹp bản trùng lặp sau khi land. Mặc định là dry-run và chỉ đóng các PR được liệt kê rõ ràng khi `apply=true`. Trước khi thay đổi GitHub, nó xác minh rằng PR đã land đã được merge và mỗi bản trùng lặp có một issue được tham chiếu chung hoặc các hunk thay đổi chồng lấp.
 
 ```bash
 gh workflow run duplicate-after-merge.yml \
@@ -396,23 +396,23 @@ gh workflow run duplicate-after-merge.yml \
 
 Logic changed-lane cục bộ nằm trong `scripts/changed-lanes.mjs` và được thực thi bởi `scripts/check-changed.mjs`. Cổng kiểm tra cục bộ đó nghiêm ngặt hơn về ranh giới kiến trúc so với phạm vi nền tảng CI rộng:
 
-- các thay đổi production lõi chạy typecheck prod lõi và test lõi cộng với lint/guard lõi;
-- các thay đổi chỉ dành cho test lõi chỉ chạy typecheck test lõi cộng với lint lõi;
-- các thay đổi production extension chạy typecheck prod extension và test extension cộng với lint extension;
-- các thay đổi chỉ dành cho test extension chạy typecheck test extension cộng với lint extension;
-- các thay đổi SDK Plugin công khai hoặc hợp đồng plugin mở rộng sang typecheck extension vì extensions phụ thuộc vào các hợp đồng lõi đó (các đợt quét Vitest extension vẫn là công việc kiểm thử rõ ràng);
-- các bump phiên bản chỉ metadata phát hành chạy các kiểm tra phiên bản/cấu hình/phụ thuộc root có mục tiêu;
-- các thay đổi root/cấu hình không xác định fail safe sang tất cả làn kiểm tra.
+- thay đổi production lõi chạy typecheck core prod và core test cùng lint/guard lõi;
+- thay đổi chỉ kiểm thử lõi chỉ chạy typecheck core test cùng lint lõi;
+- thay đổi production extension chạy typecheck extension prod và extension test cùng lint extension;
+- thay đổi chỉ kiểm thử extension chạy typecheck extension test cùng lint extension;
+- thay đổi Plugin SDK công khai hoặc hợp đồng Plugin mở rộng sang typecheck extension vì các extension phụ thuộc vào những hợp đồng lõi đó (các lượt quét extension Vitest vẫn là công việc kiểm thử rõ ràng);
+- bump phiên bản chỉ metadata phát hành chạy các kiểm tra phiên bản/cấu hình/phụ thuộc gốc có mục tiêu;
+- thay đổi root/config không xác định fail safe sang mọi lane kiểm tra.
 
-Định tuyến changed-test cục bộ nằm trong `scripts/test-projects.test-support.mjs` và cố ý nhẹ hơn `check:changed`: các chỉnh sửa test trực tiếp tự chạy chính chúng, chỉnh sửa source ưu tiên ánh xạ rõ ràng, rồi đến test anh em và các phần phụ thuộc theo import-graph. Cấu hình gửi group-room dùng chung là một trong các ánh xạ rõ ràng: thay đổi đối với cấu hình trả lời hiển thị trong nhóm, chế độ gửi trả lời nguồn, hoặc prompt hệ thống của message-tool sẽ đi qua các test trả lời lõi cộng với các hồi quy gửi Discord và Slack để một thay đổi mặc định dùng chung thất bại trước lần push PR đầu tiên. Chỉ dùng `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` khi thay đổi đủ rộng trên toàn harness đến mức tập ánh xạ rẻ không phải là proxy đáng tin cậy.
+Định tuyến changed-test cục bộ nằm trong `scripts/test-projects.test-support.mjs` và được cố ý giữ rẻ hơn `check:changed`: chỉnh sửa kiểm thử trực tiếp chạy chính chúng, chỉnh sửa nguồn ưu tiên mapping rõ ràng, sau đó đến kiểm thử sibling và các phụ thuộc import-graph. Cấu hình gửi group-room dùng chung là một trong các mapping rõ ràng: thay đổi đối với cấu hình visible-reply nhóm, chế độ gửi trả lời nguồn, hoặc prompt hệ thống message-tool sẽ đi qua các kiểm thử trả lời lõi cùng regression gửi Discord và Slack để một thay đổi mặc định dùng chung fail trước lượt push PR đầu tiên. Chỉ dùng `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` khi thay đổi đủ rộng trên toàn harness đến mức tập mapped rẻ không còn là proxy đáng tin cậy.
 
 ## Xác thực Testbox
 
-Chạy Testbox từ root repo và ưu tiên một box mới đã được warm cho bằng chứng rộng. Trước khi dùng một cổng chậm trên một box đã được tái sử dụng, hết hạn, hoặc vừa báo cáo một lượt đồng bộ lớn bất ngờ, hãy chạy `pnpm testbox:sanity` bên trong box trước.
+Chạy Testbox từ root repo và ưu tiên một box mới đã được warm cho bằng chứng rộng. Trước khi dành một cổng chậm cho một box đã được tái sử dụng, hết hạn, hoặc vừa báo cáo một lượt sync lớn bất thường, hãy chạy `pnpm testbox:sanity` bên trong box trước.
 
-Kiểm tra sanity thất bại nhanh khi các file root bắt buộc như `pnpm-lock.yaml` biến mất hoặc khi `git status --short` hiển thị ít nhất 200 file đã theo dõi bị xóa. Điều đó thường có nghĩa trạng thái đồng bộ từ xa không phải là bản sao đáng tin cậy của PR; hãy dừng box đó và warm một box mới thay vì gỡ lỗi thất bại test sản phẩm. Với các PR xóa lớn có chủ ý, đặt `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` cho lần chạy sanity đó.
+Kiểm tra sanity fail nhanh khi các tệp root bắt buộc như `pnpm-lock.yaml` biến mất hoặc khi `git status --short` hiển thị ít nhất 200 lượt xóa tracked. Điều đó thường có nghĩa trạng thái sync từ xa không phải là bản sao đáng tin cậy của PR; hãy dừng box đó và warm một box mới thay vì gỡ lỗi thất bại kiểm thử sản phẩm. Với các PR cố ý xóa số lượng lớn, đặt `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` cho lượt chạy sanity đó.
 
-`pnpm testbox:run` cũng kết thúc một lần gọi Blacksmith CLI cục bộ nếu nó ở trong giai đoạn đồng bộ quá năm phút mà không có output sau đồng bộ. Đặt `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0` để vô hiệu hóa guard đó, hoặc dùng một giá trị mili giây lớn hơn cho các diff cục bộ lớn bất thường.
+`pnpm testbox:run` cũng chấm dứt một lượt gọi Blacksmith CLI cục bộ nếu nó ở pha sync hơn năm phút mà không có output sau sync. Đặt `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0` để tắt guard đó, hoặc dùng giá trị mili giây lớn hơn cho các diff cục bộ lớn bất thường.
 
 ## Liên quan
 

docs/vi/concepts/agent-loop.md

@@ -1,190 +1,191 @@
 ---
 read_when:
-    - Bạn cần hướng dẫn từng bước chính xác về vòng lặp tác nhân hoặc các sự kiện vòng đời
-    - Bạn đang thay đổi cơ chế xếp hàng phiên, việc ghi bản ghi phiên, hoặc hành vi khóa ghi phiên
-summary: Vòng đời vòng lặp tác tử, luồng và ngữ nghĩa chờ
+    - Bạn cần một hướng dẫn từng bước chính xác về vòng lặp tác nhân hoặc các sự kiện vòng đời
+    - Bạn đang thay đổi hành vi xếp hàng phiên, ghi bản ghi hội thoại hoặc khóa ghi phiên
+summary: Vòng đời vòng lặp tác nhân, luồng và ngữ nghĩa chờ
 title: Vòng lặp tác nhân
 x-i18n:
-    generated_at: "2026-04-29T22:35:41Z"
+    generated_at: "2026-04-30T18:38:51Z"
     model: gpt-5.5
     provider: openai
-    source_hash: 902d543bd71dd517a810d825cbe92e244fe89230f47eeada72477c657a2bec32
+    source_hash: 5466893253e1f82482284ff82db56f4c3fca018bf12e4114fad76d37cad954df
     source_path: concepts/agent-loop.md
     workflow: 16
 ---
 
-Vòng lặp agentic là toàn bộ lượt chạy “thực” của một tác tử: tiếp nhận → lắp ráp ngữ cảnh → suy luận của mô hình →
-thực thi công cụ → truyền trực tuyến phản hồi → lưu bền vững. Đây là đường dẫn có thẩm quyền biến một tin nhắn
-thành hành động và phản hồi cuối cùng, đồng thời giữ trạng thái phiên nhất quán.
+Vòng lặp tác tử là toàn bộ lượt chạy “thực” của một tác tử: tiếp nhận → lắp ráp ngữ cảnh → suy luận mô hình →
+thực thi công cụ → truyền phát phản hồi → lưu trữ bền vững. Đây là đường dẫn có thẩm quyền biến một tin nhắn
+thành các hành động và phản hồi cuối cùng, đồng thời giữ trạng thái phiên nhất quán.
 
-Trong OpenClaw, một vòng lặp là một lượt chạy đơn, được tuần tự hóa theo từng phiên, phát ra các sự kiện luồng và vòng đời
-khi mô hình suy nghĩ, gọi công cụ và truyền trực tuyến đầu ra. Tài liệu này giải thích cách vòng lặp xác thực đó được
-kết nối đầu-cuối.
+Trong OpenClaw, một vòng lặp là một lượt chạy đơn lẻ, được tuần tự hóa theo từng phiên, phát ra các sự kiện vòng đời và luồng
+khi mô hình suy nghĩ, gọi công cụ và truyền phát đầu ra. Tài liệu này giải thích cách vòng lặp xác thực đó
+được nối dây từ đầu đến cuối.
 
 ## Điểm vào
 
 - Gateway RPC: `agent` và `agent.wait`.
 - CLI: lệnh `agent`.
 
-## Cách hoạt động (cấp cao)
+## Cách hoạt động (mức cao)
 
-1. RPC `agent` xác thực tham số, phân giải phiên (sessionKey/sessionId), lưu bền vững siêu dữ liệu phiên, trả về `{ runId, acceptedAt }` ngay lập tức.
+1. RPC `agent` xác thực tham số, phân giải phiên (sessionKey/sessionId), lưu metadata phiên, trả về `{ runId, acceptedAt }` ngay lập tức.
 2. `agentCommand` chạy tác tử:
-   - phân giải mô hình + giá trị mặc định cho suy nghĩ/chi tiết/dấu vết
-   - tải ảnh chụp Skills
+   - phân giải mô hình + các mặc định thinking/verbose/trace
+   - tải snapshot Skills
    - gọi `runEmbeddedPiAgent` (runtime pi-agent-core)
-   - phát **kết thúc/lỗi vòng đời** nếu vòng lặp nhúng không phát một sự kiện như vậy
+   - phát ra **vòng đời kết thúc/lỗi** nếu vòng lặp nhúng không phát ra một sự kiện như vậy
 3. `runEmbeddedPiAgent`:
-   - tuần tự hóa các lượt chạy qua hàng đợi theo từng phiên + hàng đợi toàn cục
-   - phân giải mô hình + hồ sơ xác thực và dựng phiên pi
-   - đăng ký sự kiện pi và truyền trực tuyến các delta của trợ lý/công cụ
-   - áp đặt thời gian chờ -> hủy lượt chạy nếu vượt quá
-   - trả về payload + siêu dữ liệu sử dụng
-4. `subscribeEmbeddedPiSession` bắc cầu sự kiện pi-agent-core sang luồng `agent` của OpenClaw:
+   - tuần tự hóa các lượt chạy qua hàng đợi theo phiên + toàn cục
+   - phân giải mô hình + hồ sơ xác thực và xây dựng phiên pi
+   - đăng ký nhận sự kiện pi và truyền phát các delta của trợ lý/công cụ
+   - áp dụng timeout -> hủy lượt chạy nếu vượt quá
+   - với các lượt Codex app-server, hủy một lượt đã được chấp nhận nếu nó ngừng tạo tiến trình app-server trước một sự kiện kết thúc
+   - trả về payload + metadata sử dụng
+4. `subscribeEmbeddedPiSession` nối các sự kiện pi-agent-core với luồng `agent` của OpenClaw:
    - sự kiện công cụ => `stream: "tool"`
    - delta của trợ lý => `stream: "assistant"`
    - sự kiện vòng đời => `stream: "lifecycle"` (`phase: "start" | "end" | "error"`)
 5. `agent.wait` dùng `waitForAgentRun`:
-   - chờ **kết thúc/lỗi vòng đời** cho `runId`
+   - chờ **vòng đời kết thúc/lỗi** cho `runId`
    - trả về `{ status: ok|error|timeout, startedAt, endedAt, error? }`
 
 ## Xếp hàng + đồng thời
 
-- Các lượt chạy được tuần tự hóa theo khóa phiên (làn phiên) và tùy chọn qua một làn toàn cục.
-- Điều này ngăn tranh chấp công cụ/phiên và giữ lịch sử phiên nhất quán.
-- Các kênh nhắn tin có thể chọn chế độ hàng đợi (thu thập/điều hướng/theo dõi) để đưa vào hệ thống làn này.
+- Các lượt chạy được tuần tự hóa theo từng khóa phiên (làn phiên) và tùy chọn qua một làn toàn cục.
+- Điều này ngăn các race về công cụ/phiên và giữ lịch sử phiên nhất quán.
+- Các kênh nhắn tin có thể chọn chế độ hàng đợi (collect/steer/followup) để đưa vào hệ thống làn này.
   Xem [Hàng đợi lệnh](/vi/concepts/queue).
-- Việc ghi bản ghi hội thoại cũng được bảo vệ bằng khóa ghi phiên trên tệp phiên. Khóa này
-  nhận biết tiến trình và dựa trên tệp, nên phát hiện được các trình ghi đi vòng qua hàng đợi trong tiến trình hoặc đến từ
+- Các lượt ghi transcript cũng được bảo vệ bằng khóa ghi phiên trên tệp phiên. Khóa này
+  nhận biết tiến trình và dựa trên tệp, nên phát hiện được các trình ghi bỏ qua hàng đợi trong tiến trình hoặc đến từ
   tiến trình khác.
-- Theo mặc định, khóa ghi phiên không tái nhập. Nếu một helper cố ý lồng việc lấy
-  cùng một khóa trong khi vẫn giữ một trình ghi logic duy nhất, nó phải chọn tham gia rõ ràng bằng
+- Khóa ghi phiên mặc định không tái nhập. Nếu một helper cố ý lồng việc lấy
+  cùng một khóa trong khi vẫn giữ một trình ghi logic duy nhất, helper đó phải bật rõ ràng bằng
   `allowReentrant: true`.
 
 ## Chuẩn bị phiên + workspace
 
-- Workspace được phân giải và tạo; các lượt chạy trong sandbox có thể được chuyển hướng tới gốc workspace sandbox.
-- Skills được tải (hoặc tái sử dụng từ ảnh chụp) và tiêm vào env và prompt.
-- Các tệp bootstrap/ngữ cảnh được phân giải và tiêm vào báo cáo system prompt.
-- Khóa ghi phiên được lấy; `SessionManager` được mở và chuẩn bị trước khi truyền trực tuyến. Bất kỳ
-  đường dẫn ghi lại bản ghi hội thoại, Compaction hoặc cắt bớt nào về sau đều phải lấy cùng khóa đó trước khi mở hoặc
-  sửa đổi tệp bản ghi hội thoại.
+- Workspace được phân giải và tạo; các lượt chạy trong sandbox có thể chuyển hướng đến root workspace sandbox.
+- Skills được tải (hoặc dùng lại từ snapshot) và được chèn vào env và prompt.
+- Các tệp bootstrap/ngữ cảnh được phân giải và chèn vào báo cáo system prompt.
+- Khóa ghi phiên được lấy; `SessionManager` được mở và chuẩn bị trước khi truyền phát. Mọi
+  đường dẫn viết lại transcript, Compaction hoặc cắt bớt về sau đều phải lấy cùng khóa đó trước khi mở hoặc
+  thay đổi tệp transcript.
 
 ## Lắp ráp prompt + system prompt
 
-- System prompt được dựng từ prompt cơ sở của OpenClaw, prompt Skills, ngữ cảnh bootstrap và các override theo từng lượt chạy.
-- Các giới hạn theo mô hình và token dự trữ cho Compaction được áp đặt.
-- Xem [System prompt](/vi/concepts/system-prompt) để biết mô hình thấy gì.
+- System prompt được xây dựng từ prompt nền của OpenClaw, prompt Skills, ngữ cảnh bootstrap và các override theo lượt chạy.
+- Các giới hạn theo mô hình và token dự trữ cho Compaction được áp dụng.
+- Xem [System prompt](/vi/concepts/system-prompt) để biết mô hình nhìn thấy gì.
 
-## Điểm hook (nơi bạn có thể can thiệp)
+## Điểm hook (nơi bạn có thể chặn)
 
 OpenClaw có hai hệ thống hook:
 
-- **Hook nội bộ** (hook Gateway): script hướng sự kiện cho lệnh và sự kiện vòng đời.
+- **Hook nội bộ** (hook Gateway): script theo sự kiện cho lệnh và sự kiện vòng đời.
 - **Hook Plugin**: điểm mở rộng bên trong vòng đời tác tử/công cụ và pipeline Gateway.
 
 ### Hook nội bộ (hook Gateway)
 
-- **`agent:bootstrap`**: chạy trong khi dựng tệp bootstrap trước khi system prompt được hoàn tất.
-  Dùng để thêm/xóa các tệp ngữ cảnh bootstrap.
-- **Hook lệnh**: `/new`, `/reset`, `/stop`, và các sự kiện lệnh khác (xem tài liệu Hook).
+- **`agent:bootstrap`**: chạy trong khi xây dựng tệp bootstrap trước khi system prompt được hoàn tất.
+  Dùng hook này để thêm/xóa tệp ngữ cảnh bootstrap.
+- **Hook lệnh**: `/new`, `/reset`, `/stop` và các sự kiện lệnh khác (xem tài liệu Hooks).
 
-Xem [Hook](/vi/automation/hooks) để biết cách thiết lập và ví dụ.
+Xem [Hooks](/vi/automation/hooks) để biết cách thiết lập và ví dụ.
 
-### Hook Plugin (vòng đời tác tử + gateway)
+### Hook Plugin (vòng đời tác tử + Gateway)
 
-Các hook này chạy bên trong vòng lặp tác tử hoặc pipeline gateway:
+Các hook này chạy bên trong vòng lặp tác tử hoặc pipeline Gateway:
 
-- **`before_model_resolve`**: chạy trước phiên (không có `messages`) để ghi đè nhà cung cấp/mô hình một cách tất định trước khi phân giải mô hình.
-- **`before_prompt_build`**: chạy sau khi tải phiên (có `messages`) để tiêm `prependContext`, `systemPrompt`, `prependSystemContext`, hoặc `appendSystemContext` trước khi gửi prompt. Dùng `prependContext` cho văn bản động theo từng lượt và các trường ngữ cảnh hệ thống cho hướng dẫn ổn định nên nằm trong không gian system prompt.
-- **`before_agent_start`**: hook tương thích cũ có thể chạy ở một trong hai pha; ưu tiên các hook rõ ràng ở trên.
-- **`before_agent_reply`**: chạy sau các hành động inline và trước lệnh gọi LLM, cho phép Plugin nhận lượt và trả về phản hồi tổng hợp hoặc làm im lặng toàn bộ lượt.
-- **`agent_end`**: kiểm tra danh sách tin nhắn cuối cùng và siêu dữ liệu lượt chạy sau khi hoàn tất.
+- **`before_model_resolve`**: chạy trước phiên (không có `messages`) để override provider/model một cách tất định trước khi phân giải mô hình.
+- **`before_prompt_build`**: chạy sau khi tải phiên (có `messages`) để chèn `prependContext`, `systemPrompt`, `prependSystemContext` hoặc `appendSystemContext` trước khi gửi prompt. Dùng `prependContext` cho văn bản động theo lượt và các trường system-context cho hướng dẫn ổn định nên nằm trong không gian system prompt.
+- **`before_agent_start`**: hook tương thích kế thừa có thể chạy trong một trong hai pha; ưu tiên các hook rõ ràng ở trên.
+- **`before_agent_reply`**: chạy sau inline actions và trước lệnh gọi LLM, cho phép Plugin nhận lượt và trả về phản hồi tổng hợp hoặc im lặng hoàn toàn lượt đó.
+- **`agent_end`**: kiểm tra danh sách tin nhắn cuối cùng và metadata lượt chạy sau khi hoàn tất.
 - **`before_compaction` / `after_compaction`**: quan sát hoặc chú thích các chu kỳ Compaction.
-- **`before_tool_call` / `after_tool_call`**: chặn và xử lý tham số/kết quả công cụ.
-- **`before_install`**: kiểm tra phát hiện quét tích hợp và tùy chọn chặn cài đặt skill hoặc Plugin.
-- **`tool_result_persist`**: biến đổi đồng bộ kết quả công cụ trước khi chúng được ghi vào bản ghi hội thoại phiên do OpenClaw sở hữu.
+- **`before_tool_call` / `after_tool_call`**: chặn tham số/kết quả công cụ.
+- **`before_install`**: kiểm tra các phát hiện quét tích hợp sẵn và tùy chọn chặn cài đặt skill hoặc Plugin.
+- **`tool_result_persist`**: biến đổi đồng bộ kết quả công cụ trước khi chúng được ghi vào transcript phiên do OpenClaw sở hữu.
 - **`message_received` / `message_sending` / `message_sent`**: hook tin nhắn đến + đi.
 - **`session_start` / `session_end`**: ranh giới vòng đời phiên.
 - **`gateway_start` / `gateway_stop`**: sự kiện vòng đời gateway.
 
-Quy tắc quyết định hook cho bảo vệ gửi đi/công cụ:
+Quy tắc quyết định hook cho guard đầu ra/công cụ:
 
 - `before_tool_call`: `{ block: true }` là kết thúc và dừng các handler ưu tiên thấp hơn.
-- `before_tool_call`: `{ block: false }` là không thao tác và không xóa chặn trước đó.
+- `before_tool_call`: `{ block: false }` là no-op và không xóa block trước đó.
 - `before_install`: `{ block: true }` là kết thúc và dừng các handler ưu tiên thấp hơn.
-- `before_install`: `{ block: false }` là không thao tác và không xóa chặn trước đó.
+- `before_install`: `{ block: false }` là no-op và không xóa block trước đó.
 - `message_sending`: `{ cancel: true }` là kết thúc và dừng các handler ưu tiên thấp hơn.
-- `message_sending`: `{ cancel: false }` là không thao tác và không xóa hủy trước đó.
+- `message_sending`: `{ cancel: false }` là no-op và không xóa cancel trước đó.
 
 Xem [Hook Plugin](/vi/plugins/hooks) để biết API hook và chi tiết đăng ký.
 
-Các harness có thể điều chỉnh các hook này theo cách khác. Harness app-server Codex giữ
-hook Plugin OpenClaw làm hợp đồng tương thích cho các bề mặt phản chiếu đã được tài liệu hóa,
-trong khi hook gốc Codex vẫn là một cơ chế Codex cấp thấp riêng biệt.
+Harness có thể điều chỉnh các hook này theo cách khác. Harness Codex app-server giữ
+hook Plugin OpenClaw làm hợp đồng tương thích cho các bề mặt được mirror có tài liệu,
+trong khi hook native của Codex vẫn là một cơ chế Codex cấp thấp riêng biệt.
 
-## Truyền trực tuyến + phản hồi từng phần
+## Truyền phát + phản hồi một phần
 
-- Delta của trợ lý được truyền trực tuyến từ pi-agent-core và phát ra dưới dạng sự kiện `assistant`.
-- Truyền trực tuyến theo khối có thể phát phản hồi từng phần trên `text_end` hoặc `message_end`.
-- Truyền trực tuyến phần suy luận có thể được phát dưới dạng một luồng riêng hoặc dưới dạng phản hồi khối.
-- Xem [Truyền trực tuyến](/vi/concepts/streaming) để biết hành vi chia đoạn và phản hồi khối.
+- Delta của trợ lý được truyền phát từ pi-agent-core và phát ra dưới dạng sự kiện `assistant`.
+- Truyền phát block có thể phát ra phản hồi một phần ở `text_end` hoặc `message_end`.
+- Truyền phát reasoning có thể được phát ra dưới dạng một luồng riêng hoặc dưới dạng phản hồi block.
+- Xem [Truyền phát](/vi/concepts/streaming) để biết hành vi chia chunk và phản hồi block.
 
 ## Thực thi công cụ + công cụ nhắn tin
 
 - Sự kiện bắt đầu/cập nhật/kết thúc công cụ được phát trên luồng `tool`.
 - Kết quả công cụ được làm sạch về kích thước và payload hình ảnh trước khi ghi log/phát ra.
-- Các lần gửi của công cụ nhắn tin được theo dõi để chặn xác nhận trợ lý trùng lặp.
+- Các lượt gửi bằng công cụ nhắn tin được theo dõi để ngăn xác nhận trợ lý trùng lặp.
 
-## Định hình + chặn phản hồi
+## Định hình phản hồi + triệt tiêu
 
 - Payload cuối cùng được lắp ráp từ:
-  - văn bản trợ lý (và phần suy luận tùy chọn)
-  - tóm tắt công cụ inline (khi chi tiết + được phép)
-  - văn bản lỗi trợ lý khi mô hình gặp lỗi
+  - văn bản trợ lý (và reasoning tùy chọn)
+  - tóm tắt công cụ inline (khi verbose + được phép)
+  - văn bản lỗi trợ lý khi mô hình lỗi
 - Token im lặng chính xác `NO_REPLY` / `no_reply` được lọc khỏi
   payload gửi đi.
-- Bản sao trùng lặp của công cụ nhắn tin bị loại bỏ khỏi danh sách payload cuối cùng.
-- Nếu không còn payload có thể hiển thị và một công cụ gặp lỗi, một phản hồi lỗi công cụ dự phòng được phát ra
+- Bản trùng lặp của công cụ nhắn tin bị xóa khỏi danh sách payload cuối cùng.
+- Nếu không còn payload có thể render và một công cụ bị lỗi, phản hồi lỗi công cụ dự phòng được phát ra
   (trừ khi công cụ nhắn tin đã gửi phản hồi người dùng có thể thấy).
 
 ## Compaction + thử lại
 
-- Compaction tự động phát sự kiện luồng `compaction` và có thể kích hoạt thử lại.
-- Khi thử lại, bộ đệm trong bộ nhớ và tóm tắt công cụ được đặt lại để tránh đầu ra trùng lặp.
+- Auto-compaction phát ra sự kiện luồng `compaction` và có thể kích hoạt thử lại.
+- Khi thử lại, buffer trong bộ nhớ và tóm tắt công cụ được đặt lại để tránh đầu ra trùng lặp.
 - Xem [Compaction](/vi/concepts/compaction) để biết pipeline Compaction.
 
-## Luồng sự kiện (hiện nay)
+## Luồng sự kiện (hiện tại)
 
-- `lifecycle`: do `subscribeEmbeddedPiSession` phát ra (và như một phương án dự phòng bởi `agentCommand`)
-- `assistant`: delta truyền trực tuyến từ pi-agent-core
-- `tool`: sự kiện công cụ truyền trực tuyến từ pi-agent-core
+- `lifecycle`: do `subscribeEmbeddedPiSession` phát ra (và do `agentCommand` phát ra làm dự phòng)
+- `assistant`: delta được truyền phát từ pi-agent-core
+- `tool`: sự kiện công cụ được truyền phát từ pi-agent-core
 
 ## Xử lý kênh chat
 
-- Delta của trợ lý được đệm thành tin nhắn `delta` của chat.
-- Một `final` của chat được phát khi **kết thúc/lỗi vòng đời**.
+- Delta của trợ lý được buffer thành tin nhắn chat `delta`.
+- Một chat `final` được phát ra khi **vòng đời kết thúc/lỗi**.
 
-## Thời gian chờ
+## Timeout
 
-- Mặc định của `agent.wait`: 30 giây (chỉ phần chờ). Tham số `timeoutMs` ghi đè.
-- Runtime tác tử: mặc định `agents.defaults.timeoutSeconds` là 172800 giây (48 giờ); được áp đặt trong bộ hẹn giờ hủy của `runEmbeddedPiAgent`.
-- Runtime Cron: `timeoutSeconds` cho lượt tác tử cô lập do cron sở hữu. Bộ lập lịch bắt đầu bộ hẹn giờ đó khi thực thi bắt đầu, hủy lượt chạy nền ở hạn chót đã cấu hình, rồi chạy dọn dẹp có giới hạn trước khi ghi nhận thời gian chờ để một phiên con lỗi thời không thể khiến làn bị kẹt.
-- Khôi phục phiên bị kẹt: khi bật chẩn đoán, `diagnostics.stuckSessionWarnMs` phát hiện các phiên `processing` kéo dài. Các lượt chạy nhúng đang hoạt động, thao tác phản hồi đang hoạt động và tác vụ làn phiên đang hoạt động mặc định chỉ cảnh báo; nếu chẩn đoán cho thấy không có công việc đang hoạt động cho phiên, watchdog giải phóng làn phiên bị ảnh hưởng để công việc khởi động đang xếp hàng có thể thoát.
-- Thời gian chờ nhàn rỗi của mô hình: OpenClaw hủy yêu cầu mô hình khi không có đoạn phản hồi nào đến trước cửa sổ nhàn rỗi. `models.providers.<id>.timeoutSeconds` mở rộng watchdog nhàn rỗi này cho các nhà cung cấp cục bộ/tự lưu trữ chậm; nếu không, OpenClaw dùng `agents.defaults.timeoutSeconds` khi được cấu hình, mặc định giới hạn ở 120 giây. Các lượt chạy do Cron kích hoạt không có thời gian chờ mô hình hoặc tác tử rõ ràng sẽ tắt watchdog nhàn rỗi và dựa vào thời gian chờ ngoài của cron.
-- Thời gian chờ yêu cầu HTTP của nhà cung cấp: `models.providers.<id>.timeoutSeconds` áp dụng cho các lần fetch HTTP mô hình của nhà cung cấp đó, bao gồm kết nối, header, body, thời gian chờ yêu cầu SDK, xử lý hủy guarded-fetch tổng thể và watchdog nhàn rỗi luồng mô hình. Dùng thiết lập này cho các nhà cung cấp cục bộ/tự lưu trữ chậm như Ollama trước khi tăng thời gian chờ runtime của toàn bộ tác tử.
+- Mặc định của `agent.wait`: 30 giây (chỉ phần chờ). Tham số `timeoutMs` override.
+- Runtime tác tử: mặc định `agents.defaults.timeoutSeconds` là 172800 giây (48 giờ); được áp dụng trong timer hủy của `runEmbeddedPiAgent`.
+- Runtime Cron: `timeoutSeconds` của lượt tác tử biệt lập do Cron sở hữu. Bộ lập lịch bắt đầu timer đó khi thực thi bắt đầu, hủy lượt chạy nền bên dưới tại deadline đã cấu hình, rồi chạy cleanup có giới hạn trước khi ghi nhận timeout để phiên con cũ không thể làm kẹt làn.
+- Khôi phục phiên bị kẹt: khi bật diagnostics, `diagnostics.stuckSessionWarnMs` phát hiện các phiên `processing` kéo dài. Các lượt chạy nhúng đang hoạt động, thao tác phản hồi đang hoạt động và tác vụ làn phiên đang hoạt động mặc định chỉ cảnh báo; nếu diagnostics cho thấy không có công việc đang hoạt động cho phiên, watchdog sẽ nhả làn phiên bị ảnh hưởng để công việc khởi động đang xếp hàng có thể thoát.
+- Timeout rỗi của mô hình: OpenClaw hủy một yêu cầu mô hình khi không có chunk phản hồi nào đến trước cửa sổ rỗi. `models.providers.<id>.timeoutSeconds` mở rộng watchdog rỗi này cho các provider local/tự host chậm; nếu không, OpenClaw dùng `agents.defaults.timeoutSeconds` khi được cấu hình, mặc định bị giới hạn ở 120 giây. Các lượt chạy do Cron kích hoạt không có timeout mô hình hoặc tác tử rõ ràng sẽ tắt watchdog rỗi và dựa vào timeout ngoài của Cron.
+- Timeout yêu cầu HTTP của provider: `models.providers.<id>.timeoutSeconds` áp dụng cho các lượt fetch HTTP mô hình của provider đó, bao gồm connect, header, body, timeout yêu cầu SDK, xử lý hủy guarded-fetch tổng thể và watchdog rỗi luồng mô hình. Dùng mục này cho các provider local/tự host chậm như Ollama trước khi tăng timeout runtime toàn bộ tác tử.
 
-## Những nơi có thể kết thúc sớm
+## Nơi mọi thứ có thể kết thúc sớm
 
-- Thời gian chờ tác tử (hủy)
+- Timeout tác tử (hủy)
 - AbortSignal (hủy)
-- Gateway ngắt kết nối hoặc RPC hết thời gian chờ
-- `agent.wait` hết thời gian chờ (chỉ chờ, không dừng tác tử)
+- Gateway ngắt kết nối hoặc timeout RPC
+- Timeout `agent.wait` (chỉ chờ, không dừng tác tử)
 
 ## Liên quan
 
 - [Công cụ](/vi/tools) — công cụ tác tử có sẵn
-- [Hook](/vi/automation/hooks) — script hướng sự kiện được kích hoạt bởi sự kiện vòng đời tác tử
-- [Compaction](/vi/concepts/compaction) — cách tóm tắt các cuộc trò chuyện dài
+- [Hooks](/vi/automation/hooks) — script theo sự kiện được kích hoạt bởi các sự kiện vòng đời tác tử
+- [Compaction](/vi/concepts/compaction) — cách tóm tắt các cuộc hội thoại dài
 - [Phê duyệt Exec](/vi/tools/exec-approvals) — cổng phê duyệt cho lệnh shell
-- [Suy nghĩ](/vi/tools/thinking) — cấu hình cấp độ suy nghĩ/suy luận
+- [Thinking](/vi/tools/thinking) — cấu hình mức thinking/reasoning

docs/vi/concepts/queue.md

@@ -1,60 +1,60 @@
 ---
 read_when:
-    - Thay đổi cách thực thi hoặc tính đồng thời của tự động trả lời
+    - Thay đổi cách thực thi hoặc mức độ đồng thời của tính năng trả lời tự động
     - Giải thích các chế độ /queue hoặc hành vi điều hướng tin nhắn
-summary: Các chế độ hàng đợi tự động trả lời, giá trị mặc định và ghi đè theo từng phiên
+summary: Chế độ hàng đợi tự động trả lời, giá trị mặc định và ghi đè theo từng phiên
 title: Hàng đợi lệnh
 x-i18n:
-    generated_at: "2026-04-30T09:36:09Z"
+    generated_at: "2026-04-30T18:38:39Z"
     model: gpt-5.5
     provider: openai
-    source_hash: 2ac0c0ded9558b080714fa4b8be0d552f985911bf19b427020f9654ae4955b2d
+    source_hash: fbf1bb1ffd4ce06fa138f63e31651b8821226d9c95dd6b93d68326a5fb91fdd0
     source_path: concepts/queue.md
     workflow: 16
 ---
 
-Chúng tôi tuần tự hóa các lượt chạy tự động trả lời đến (mọi kênh) qua một hàng đợi nhỏ trong tiến trình để ngăn nhiều lượt chạy agent va chạm nhau, đồng thời vẫn cho phép xử lý song song an toàn giữa các phiên.
+Chúng tôi tuần tự hóa các lượt chạy tự động trả lời đến (tất cả các kênh) thông qua một hàng đợi nhỏ trong tiến trình để ngăn nhiều lượt chạy tác nhân va chạm với nhau, trong khi vẫn cho phép song song an toàn giữa các phiên.
 
-## Lý do
+## Vì sao
 
-- Các lượt chạy tự động trả lời có thể tốn kém (lệnh gọi LLM) và có thể va chạm khi nhiều tin nhắn đến gần như cùng lúc.
-- Tuần tự hóa giúp tránh tranh chấp tài nguyên dùng chung (tệp phiên, nhật ký, stdin của CLI) và giảm khả năng gặp giới hạn tốc độ từ upstream.
+- Các lượt chạy tự động trả lời có thể tốn kém (lệnh gọi LLM) và có thể va chạm khi nhiều tin nhắn đến gần nhau.
+- Tuần tự hóa giúp tránh cạnh tranh tài nguyên dùng chung (tệp phiên, nhật ký, stdin của CLI) và giảm khả năng gặp giới hạn tốc độ từ thượng nguồn.
 
 ## Cách hoạt động
 
-- Một hàng đợi FIFO nhận biết lane sẽ xả từng lane với giới hạn đồng thời có thể cấu hình (mặc định là 1 cho các lane chưa cấu hình; main mặc định là 4, subagent là 8).
+- Một hàng đợi FIFO có nhận biết lane xả từng lane với giới hạn đồng thời có thể cấu hình (mặc định là 1 cho các lane chưa cấu hình; main mặc định là 4, subagent là 8).
 - `runEmbeddedPiAgent` đưa vào hàng đợi theo **khóa phiên** (lane `session:<key>`) để bảo đảm mỗi phiên chỉ có một lượt chạy đang hoạt động.
-- Sau đó, mỗi lượt chạy phiên được đưa vào một **lane toàn cục** (`main` theo mặc định) để mức song song tổng thể được giới hạn bởi `agents.defaults.maxConcurrent`.
-- Khi bật ghi nhật ký chi tiết, các lượt chạy trong hàng đợi sẽ phát một thông báo ngắn nếu đã chờ hơn khoảng 2 giây trước khi bắt đầu.
-- Chỉ báo đang nhập vẫn kích hoạt ngay khi đưa vào hàng đợi (khi kênh hỗ trợ), nên trải nghiệm người dùng không đổi trong lúc chờ đến lượt.
+- Sau đó, mỗi lượt chạy phiên được đưa vào một **lane toàn cục** (`main` theo mặc định) để tổng mức song song được giới hạn bởi `agents.defaults.maxConcurrent`.
+- Khi bật ghi nhật ký chi tiết, các lượt chạy trong hàng đợi sẽ phát ra một thông báo ngắn nếu chúng chờ hơn khoảng 2 giây trước khi bắt đầu.
+- Chỉ báo đang nhập vẫn kích hoạt ngay khi đưa vào hàng đợi (khi kênh hỗ trợ), nên trải nghiệm người dùng không đổi trong lúc chúng tôi chờ đến lượt.
 
 ## Mặc định
 
-Khi chưa đặt, mọi bề mặt kênh đến dùng:
+Khi chưa đặt, tất cả bề mặt kênh đến dùng:
 
 - `mode: "steer"`
 - `debounceMs: 500`
 - `cap: 20`
 - `drop: "summarize"`
 
-`steer` là mặc định vì nó giữ lượt mô hình đang hoạt động phản hồi nhanh mà không
+`steer` là mặc định vì nó giữ cho lượt mô hình đang hoạt động phản hồi nhanh mà không
 khởi động lượt chạy phiên thứ hai. Nó xả tất cả tin nhắn điều hướng đã đến
-trước ranh giới mô hình tiếp theo. Nếu lượt chạy hiện tại không thể nhận điều hướng,
-OpenClaw sẽ quay về một mục hàng đợi followup.
+trước ranh giới mô hình tiếp theo. Nếu lượt chạy hiện tại không thể chấp nhận điều hướng,
+OpenClaw quay về một mục hàng đợi followup.
 
 ## Chế độ hàng đợi
 
-Tin nhắn đến có thể điều hướng lượt chạy hiện tại, chờ một lượt followup, hoặc cả hai:
+Tin nhắn đến có thể điều hướng lượt chạy hiện tại, chờ một lượt followup, hoặc làm cả hai:
 
-- `steer`: đưa tin nhắn điều hướng vào runtime đang hoạt động. Pi chuyển tất cả tin nhắn điều hướng đang chờ **sau khi lượt assistant hiện tại thực thi xong các lệnh gọi công cụ**, trước lệnh gọi LLM tiếp theo; Codex app-server nhận một `turn/steer` được gom lô. Nếu lượt chạy không chủ động streaming hoặc không hỗ trợ điều hướng, OpenClaw sẽ quay về một mục hàng đợi followup.
-- `queue` (cũ): điều hướng từng tin nhắn một kiểu cũ. Pi chuyển một tin nhắn điều hướng trong hàng đợi tại mỗi ranh giới mô hình; Codex app-server nhận các yêu cầu `turn/steer` riêng biệt. Ưu tiên `steer` trừ khi bạn cần hành vi tuần tự hóa trước đây.
-- `followup`: đưa từng tin nhắn vào hàng đợi cho một lượt agent về sau sau khi lượt chạy hiện tại kết thúc.
-- `collect`: gộp các tin nhắn trong hàng đợi thành một lượt followup **duy nhất** sau khoảng lặng. Nếu tin nhắn nhắm đến các kênh/luồng khác nhau, chúng được xả riêng để giữ đúng định tuyến.
-- `steer-backlog` (còn gọi là `steer+backlog`): điều hướng ngay **và** giữ cùng tin nhắn đó cho một lượt followup.
-- `interrupt` (cũ): hủy lượt chạy đang hoạt động cho phiên đó, rồi chạy tin nhắn mới nhất.
+- `steer`: đưa tin nhắn điều hướng vào runtime đang hoạt động. Pi gửi tất cả tin nhắn điều hướng đang chờ **sau khi lượt trợ lý hiện tại thực thi xong các lệnh gọi công cụ của nó**, trước lệnh gọi LLM tiếp theo; Codex app-server nhận một `turn/steer` được gom lô. Nếu lượt chạy không đang stream chủ động hoặc không có điều hướng, OpenClaw quay về một mục hàng đợi followup.
+- `queue` (kế thừa): điều hướng cũ theo từng tin nhắn một. Pi gửi một tin nhắn điều hướng trong hàng đợi tại mỗi ranh giới mô hình; Codex app-server nhận các yêu cầu `turn/steer` riêng biệt. Ưu tiên `steer` trừ khi bạn cần hành vi tuần tự hóa trước đó.
+- `followup`: đưa từng tin nhắn vào hàng đợi cho một lượt tác nhân sau này sau khi lượt chạy hiện tại kết thúc.
+- `collect`: gộp các tin nhắn trong hàng đợi thành một lượt followup **duy nhất** sau khoảng lặng. Nếu tin nhắn nhắm đến các kênh/luồng khác nhau, chúng sẽ được xả riêng lẻ để bảo toàn định tuyến.
+- `steer-backlog` (còn gọi là `steer+backlog`): điều hướng ngay **và** giữ lại cùng tin nhắn đó cho một lượt followup.
+- `interrupt` (kế thừa): hủy lượt chạy đang hoạt động cho phiên đó, rồi chạy tin nhắn mới nhất.
 
-Steer-backlog nghĩa là bạn có thể nhận một phản hồi followup sau lượt chạy đã được điều hướng, nên
-các bề mặt streaming có thể trông như bị trùng lặp. Ưu tiên `collect`/`steer` nếu bạn muốn
+Steer-backlog nghĩa là bạn có thể nhận phản hồi followup sau lượt chạy đã được điều hướng, nên
+các bề mặt streaming có thể trông giống như bị trùng lặp. Ưu tiên `collect`/`steer` nếu bạn muốn
 một phản hồi cho mỗi tin nhắn đến.
 
 Để biết thời điểm và hành vi phụ thuộc theo từng runtime, xem
@@ -78,12 +78,12 @@ Cấu hình toàn cục hoặc theo kênh qua `messages.queue`:
 
 ## Tùy chọn hàng đợi
 
-Các tùy chọn áp dụng cho `followup`, `collect`, và `steer-backlog` (và cho `steer` hoặc `queue` cũ khi điều hướng quay về followup):
+Các tùy chọn áp dụng cho `followup`, `collect`, và `steer-backlog` (và cho `steer` hoặc `queue` kế thừa khi điều hướng quay về followup):
 
-- `debounceMs`: khoảng lặng trước khi xả các followup trong hàng đợi. Số thuần là mili giây; các đơn vị `ms`, `s`, `m`, `h`, và `d` được tùy chọn `/queue` chấp nhận.
-- `cap`: số tin nhắn tối đa trong hàng đợi mỗi phiên. Giá trị dưới `1` bị bỏ qua.
-- `drop: "summarize"`: mặc định. Bỏ các mục cũ nhất trong hàng đợi khi cần, giữ bản tóm tắt gọn, và chèn chúng như một prompt followup tổng hợp.
-- `drop: "old"`: bỏ các mục cũ nhất trong hàng đợi khi cần, không giữ bản tóm tắt.
+- `debounceMs`: khoảng lặng trước khi xả các followup trong hàng đợi. Số trần là mili giây; các đơn vị `ms`, `s`, `m`, `h`, và `d` được tùy chọn `/queue` chấp nhận.
+- `cap`: số tin nhắn tối đa trong hàng đợi mỗi phiên. Các giá trị dưới `1` bị bỏ qua.
+- `drop: "summarize"`: mặc định. Bỏ các mục cũ nhất trong hàng đợi khi cần, giữ lại tóm tắt cô đọng và chèn chúng dưới dạng prompt followup tổng hợp.
+- `drop: "old"`: bỏ các mục cũ nhất trong hàng đợi khi cần, không giữ lại tóm tắt.
 - `drop: "new"`: từ chối tin nhắn mới nhất khi hàng đợi đã đầy.
 
 Mặc định: `debounceMs: 500`, `cap: 20`, `drop: summarize`.
@@ -92,35 +92,36 @@ Mặc định: `debounceMs: 500`, `cap: 20`, `drop: summarize`.
 
 Để chọn chế độ, OpenClaw phân giải:
 
-1. Ghi đè `/queue` nội tuyến hoặc đã lưu cho từng phiên.
+1. Ghi đè `/queue` nội tuyến hoặc đã lưu theo phiên.
 2. `messages.queue.byChannel.<channel>`.
 3. `messages.queue.mode`.
 4. Mặc định `steer`.
 
 Đối với tùy chọn, các tùy chọn `/queue` nội tuyến hoặc đã lưu thắng cấu hình. Sau đó
-debounce theo kênh (`messages.queue.debounceMsByChannel`), mặc định debounce của plugin,
-các tùy chọn `messages.queue` toàn cục, và mặc định tích hợp sẵn được
-áp dụng. `cap` và `drop` là tùy chọn toàn cục/phiên, không phải khóa cấu hình theo kênh.
+áp dụng debounce theo kênh (`messages.queue.debounceMsByChannel`), mặc định debounce của plugin,
+các tùy chọn `messages.queue` toàn cục, và mặc định tích hợp sẵn.
+`cap` và `drop` là tùy chọn toàn cục/phiên, không phải khóa cấu hình theo kênh.
 
 ## Ghi đè theo phiên
 
-- Gửi `/queue <mode>` dưới dạng lệnh độc lập để lưu chế độ cho phiên hiện tại.
+- Gửi `/queue <mode>` như một lệnh độc lập để lưu chế độ cho phiên hiện tại.
 - Có thể kết hợp các tùy chọn: `/queue collect debounce:0.5s cap:25 drop:summarize`
-- `/queue default` hoặc `/queue reset` xóa ghi đè của phiên.
+- `/queue default` hoặc `/queue reset` xóa ghi đè phiên.
 
 ## Phạm vi và bảo đảm
 
-- Áp dụng cho các lượt chạy agent tự động trả lời trên mọi kênh đến dùng pipeline trả lời của Gateway (WhatsApp web, Telegram, Slack, Discord, Signal, iMessage, webchat, v.v.).
+- Áp dụng cho các lượt chạy tác nhân tự động trả lời trên tất cả các kênh đến dùng pipeline trả lời Gateway (WhatsApp web, Telegram, Slack, Discord, Signal, iMessage, webchat, v.v.).
 - Lane mặc định (`main`) là toàn tiến trình cho inbound + Heartbeat chính; đặt `agents.defaults.maxConcurrent` để cho phép nhiều phiên chạy song song.
-- Có thể tồn tại các lane bổ sung (ví dụ `cron`, `cron-nested`, `nested`, `subagent`) để các tác vụ nền có thể chạy song song mà không chặn trả lời đến. Các lượt agent Cron cô lập giữ một slot `cron` trong khi phần thực thi agent bên trong dùng `cron-nested`; cả hai dùng `cron.maxConcurrentRuns`. Các luồng `nested` không phải Cron và dùng chung giữ hành vi lane riêng. Các lượt chạy tách rời này được theo dõi dưới dạng [tác vụ nền](/vi/automation/tasks).
-- Lane theo phiên bảo đảm tại một thời điểm chỉ có một lượt chạy agent chạm vào một phiên nhất định.
-- Không có phụ thuộc bên ngoài hoặc luồng worker nền; chỉ TypeScript + promises thuần.
+- Có thể tồn tại các lane bổ sung (ví dụ `cron`, `cron-nested`, `nested`, `subagent`) để các công việc nền có thể chạy song song mà không chặn trả lời đến. Các lượt tác nhân cron cô lập giữ một slot `cron` trong khi phần thực thi tác nhân bên trong dùng `cron-nested`; cả hai dùng `cron.maxConcurrentRuns`. Các luồng `nested` không phải cron dùng chung giữ hành vi lane riêng của chúng. Các lượt chạy tách rời này được theo dõi dưới dạng [tác vụ nền](/vi/automation/tasks).
+- Lane theo phiên bảo đảm chỉ một lượt chạy tác nhân chạm vào một phiên nhất định tại một thời điểm.
+- Không có phụ thuộc bên ngoài hoặc luồng worker nền; chỉ TypeScript + promises.
 
 ## Khắc phục sự cố
 
-- Nếu các lệnh có vẻ bị kẹt, bật nhật ký chi tiết và tìm các dòng “queued for …ms” để xác nhận hàng đợi đang xả.
+- Nếu lệnh có vẻ bị kẹt, bật nhật ký chi tiết và tìm các dòng “queued for …ms” để xác nhận hàng đợi đang xả.
 - Nếu bạn cần độ sâu hàng đợi, bật nhật ký chi tiết và theo dõi các dòng thời gian hàng đợi.
-- Khi bật chẩn đoán, các phiên còn ở trạng thái `processing` quá `diagnostics.stuckSessionWarnMs` sẽ ghi cảnh báo phiên bị kẹt. Các lượt chạy nhúng đang hoạt động, thao tác trả lời đang hoạt động, và tác vụ lane đang hoạt động mặc định vẫn chỉ cảnh báo; sổ sách khởi động đã cũ mà không có công việc phiên đang hoạt động có thể nhả lane phiên bị ảnh hưởng để công việc trong hàng đợi được xả.
+- Các lượt chạy Codex app-server chấp nhận một lượt rồi ngừng phát tiến trình sẽ bị adapter Codex ngắt để lane phiên đang hoạt động có thể được giải phóng thay vì chờ timeout của lượt chạy ngoài.
+- Khi bật chẩn đoán, các phiên vẫn ở trạng thái `processing` quá `diagnostics.stuckSessionWarnMs` sẽ ghi cảnh báo phiên bị kẹt. Các lượt chạy nhúng đang hoạt động, thao tác trả lời đang hoạt động và tác vụ lane đang hoạt động mặc định vẫn chỉ cảnh báo; sổ sách khởi động đã cũ mà không có công việc phiên đang hoạt động có thể giải phóng lane phiên bị ảnh hưởng để công việc trong hàng đợi được xả.
 
 ## Liên quan
 

docs/vi/reference/test.md

@@ -1,56 +1,57 @@
 ---
 read_when:
     - Chạy hoặc sửa các bài kiểm thử
-summary: Cách chạy kiểm thử cục bộ (vitest) và khi nào dùng các chế độ force/coverage
+summary: Cách chạy kiểm thử cục bộ (vitest) và khi nào nên dùng chế độ force/coverage
 title: Kiểm thử
 x-i18n:
-    generated_at: "2026-04-29T23:13:19Z"
+    generated_at: "2026-04-30T18:38:33Z"
     model: gpt-5.5
     provider: openai
-    source_hash: 9328d6f0383b5067fa8bb5d0f1bf22a3b9048a267908bf85167842ddc3d12e42
+    source_hash: 131f2bad3b2806d28394213cec38d632d106ddbf8ff04d06345ab8046fb8bcf2
     source_path: reference/test.md
     workflow: 16
 ---
 
-- Bộ công cụ kiểm thử đầy đủ (bộ kiểm thử, kiểm thử trực tiếp, Docker): [Kiểm thử](/vi/help/testing)
+- Bộ công cụ kiểm thử đầy đủ (bộ kiểm thử, trực tiếp, Docker): [Kiểm thử](/vi/help/testing)
 
-- `pnpm test:force`: Dừng mọi tiến trình Gateway còn sót lại đang giữ cổng điều khiển mặc định, sau đó chạy toàn bộ bộ Vitest với một cổng Gateway biệt lập để các kiểm thử máy chủ không va chạm với một phiên bản đang chạy. Dùng lệnh này khi một lần chạy Gateway trước đó khiến cổng 18789 bị chiếm.
-- `pnpm test:coverage`: Chạy bộ đơn vị với coverage V8 (thông qua `vitest.unit.config.ts`). Đây là gate coverage đơn vị theo tệp đã tải, không phải coverage toàn bộ tệp trong toàn repo. Ngưỡng là 70% cho dòng/hàm/câu lệnh và 55% cho nhánh. Vì `coverage.all` là false, gate này đo các tệp được bộ coverage đơn vị tải thay vì xem mọi tệp nguồn thuộc lane đã tách là chưa được coverage.
+- `pnpm test:force`: Diệt mọi tiến trình Gateway còn sót lại đang giữ cổng điều khiển mặc định, sau đó chạy toàn bộ bộ Vitest với một cổng Gateway cô lập để các kiểm thử máy chủ không xung đột với một phiên bản đang chạy. Dùng lệnh này khi một lần chạy Gateway trước đó để lại cổng 18789 bị chiếm dụng.
+- `pnpm test:coverage`: Chạy bộ kiểm thử đơn vị với coverage V8 (thông qua `vitest.unit.config.ts`). Đây là cổng coverage đơn vị theo tệp đã được tải, không phải coverage toàn bộ repo cho mọi tệp. Ngưỡng là 70% dòng/hàm/câu lệnh và 55% nhánh. Vì `coverage.all` là false, cổng này đo các tệp được bộ coverage đơn vị tải thay vì coi mọi tệp nguồn theo làn tách là chưa được cover.
 - `pnpm test:coverage:changed`: Chỉ chạy coverage đơn vị cho các tệp đã thay đổi kể từ `origin/main`.
-- `pnpm test:changed`: lần chạy kiểm thử thay đổi thông minh, chi phí thấp. Nó chạy các mục tiêu chính xác từ chỉnh sửa kiểm thử trực tiếp, các tệp `*.test.ts` cùng cấp, ánh xạ nguồn tường minh và đồ thị import cục bộ. Các thay đổi rộng/config/package bị bỏ qua trừ khi chúng ánh xạ đến các kiểm thử chính xác.
-- `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`: lần chạy kiểm thử thay đổi rộng tường minh. Dùng khi một chỉnh sửa về test harness/config/package nên rơi về hành vi kiểm thử thay đổi rộng hơn của Vitest.
-- `pnpm changed:lanes`: hiển thị các lane kiến trúc được kích hoạt bởi diff so với `origin/main`.
-- `pnpm check:changed`: chạy gate kiểm tra thay đổi thông minh cho diff so với `origin/main`. Nó chạy typecheck, lint và các lệnh guard cho các lane kiến trúc bị ảnh hưởng, nhưng không chạy kiểm thử Vitest. Dùng `pnpm test:changed` hoặc `pnpm test <target>` tường minh để có bằng chứng kiểm thử.
-- `pnpm test`: định tuyến các mục tiêu tệp/thư mục tường minh qua các lane Vitest có phạm vi. Các lần chạy không chỉ định mục tiêu dùng các nhóm shard cố định và mở rộng thành các cấu hình lá để thực thi song song cục bộ; nhóm plugin luôn mở rộng thành các cấu hình shard theo từng plugin thay vì một tiến trình root-project khổng lồ.
-- Các lần chạy test wrapper kết thúc bằng một tóm tắt ngắn dạng `[test] passed|failed|skipped ... in ...`. Dòng thời lượng riêng của Vitest vẫn là chi tiết theo từng shard.
-- Trạng thái kiểm thử OpenClaw dùng chung: dùng `src/test-utils/openclaw-test-state.ts` từ Vitest khi một kiểm thử cần `HOME`, `OPENCLAW_STATE_DIR`, `OPENCLAW_CONFIG_PATH`, fixture cấu hình, workspace, thư mục agent hoặc kho auth-profile biệt lập.
-- Trình trợ giúp E2E tiến trình: dùng `test/helpers/openclaw-test-instance.ts` khi một kiểm thử E2E cấp tiến trình Vitest cần Gateway đang chạy, env CLI, thu thập log và dọn dẹp ở một nơi.
-- Trình trợ giúp E2E Docker/Bash: các lane source `scripts/lib/docker-e2e-image.sh` có thể truyền `docker_e2e_test_state_shell_b64 <label> <scenario>` vào container và giải mã bằng `scripts/lib/openclaw-e2e-instance.sh`; các script nhiều home có thể truyền `docker_e2e_test_state_function_b64` và gọi `openclaw_test_state_create <label> <scenario>` trong từng luồng. Các caller cấp thấp hơn có thể dùng `scripts/lib/openclaw-test-state.mjs shell --label <name> --scenario <name>` cho một đoạn shell trong container, hoặc `node scripts/lib/openclaw-test-state.mjs -- create --label <name> --scenario <name> --env-file <path> --json` cho một tệp env host có thể source. Dấu `--` trước `create` ngăn các runtime Node mới hơn xem `--env-file` là cờ Node. Các lane Docker/Bash khởi chạy Gateway có thể source `scripts/lib/openclaw-e2e-instance.sh` bên trong container để phân giải entrypoint, khởi động OpenAI giả lập, khởi chạy Gateway foreground/background, probe readiness, xuất env trạng thái, dump log và dọn dẹp tiến trình.
-- Các lần chạy shard đầy đủ, plugin và include-pattern cập nhật dữ liệu thời gian cục bộ trong `.artifacts/vitest-shard-timings.json`; các lần chạy toàn cấu hình sau đó dùng các thời gian này để cân bằng shard chậm và nhanh. Shard CI include-pattern thêm tên shard vào khóa thời gian, nhờ đó thời gian shard đã lọc vẫn hiển thị mà không thay thế dữ liệu thời gian toàn cấu hình. Đặt `OPENCLAW_TEST_PROJECTS_TIMINGS=0` để bỏ qua artifact thời gian cục bộ.
-- Các tệp kiểm thử `plugin-sdk` và `commands` được chọn giờ định tuyến qua các lane nhẹ chuyên dụng chỉ giữ `test/setup.ts`, còn các trường hợp nặng về runtime vẫn nằm trên lane hiện có.
-- Các tệp nguồn có kiểm thử cùng cấp ánh xạ đến tệp cùng cấp đó trước khi rơi về các glob thư mục rộng hơn. Chỉnh sửa helper dưới `src/channels/plugins/contracts/test-helpers`, `src/plugin-sdk/test-helpers` và `src/plugins/contracts` dùng đồ thị import cục bộ để chạy các kiểm thử import chúng thay vì chạy rộng mọi shard khi đường dẫn phụ thuộc là chính xác.
-- `auto-reply` giờ cũng tách thành ba cấu hình chuyên dụng (`core`, `top-level`, `reply`) để harness reply không lấn át các kiểm thử trạng thái/token/helper top-level nhẹ hơn.
-- Cấu hình Vitest cơ sở giờ mặc định là `pool: "threads"` và `isolate: false`, với runner không biệt lập dùng chung được bật trên các cấu hình repo.
+- `pnpm test:changed`: lần chạy kiểm thử thay đổi thông minh, rẻ. Nó chạy các mục tiêu chính xác từ chỉnh sửa kiểm thử trực tiếp, các tệp `*.test.ts` cùng cấp, ánh xạ nguồn rõ ràng, và đồ thị import cục bộ. Các thay đổi rộng/config/package sẽ bị bỏ qua trừ khi chúng ánh xạ tới kiểm thử chính xác.
+- `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`: lần chạy kiểm thử thay đổi rộng rõ ràng. Dùng khi một chỉnh sửa test harness/config/package nên fallback về hành vi kiểm thử thay đổi rộng hơn của Vitest.
+- `pnpm changed:lanes`: hiển thị các làn kiến trúc được kích hoạt bởi diff so với `origin/main`.
+- `pnpm check:changed`: chạy cổng kiểm tra thay đổi thông minh cho diff so với `origin/main`. Nó chạy typecheck, lint, và các lệnh guard cho các làn kiến trúc bị ảnh hưởng, nhưng không chạy kiểm thử Vitest. Dùng `pnpm test:changed` hoặc `pnpm test <target>` rõ ràng để lấy bằng chứng kiểm thử.
+- `pnpm test`: định tuyến các mục tiêu tệp/thư mục rõ ràng qua các làn Vitest theo phạm vi. Các lần chạy không chỉ định mục tiêu dùng các nhóm shard cố định và mở rộng thành cấu hình lá để thực thi song song cục bộ; nhóm extension luôn mở rộng thành các cấu hình shard theo từng extension thay vì một tiến trình root-project khổng lồ.
+- Các lần chạy test wrapper kết thúc bằng tóm tắt ngắn `[test] passed|failed|skipped ... in ...`. Dòng thời lượng riêng của Vitest vẫn là chi tiết theo từng shard.
+- Trạng thái kiểm thử OpenClaw dùng chung: dùng `src/test-utils/openclaw-test-state.ts` từ Vitest khi một kiểm thử cần `HOME`, `OPENCLAW_STATE_DIR`, `OPENCLAW_CONFIG_PATH`, fixture config, workspace, thư mục agent, hoặc kho auth-profile được cô lập.
+- Helper E2E tiến trình: dùng `test/helpers/openclaw-test-instance.ts` khi một kiểm thử E2E cấp tiến trình Vitest cần một Gateway đang chạy, env CLI, ghi log, và dọn dẹp ở một nơi.
+- Helper E2E Docker/Bash: các làn source `scripts/lib/docker-e2e-image.sh` có thể truyền `docker_e2e_test_state_shell_b64 <label> <scenario>` vào container và giải mã bằng `scripts/lib/openclaw-e2e-instance.sh`; các script nhiều home có thể truyền `docker_e2e_test_state_function_b64` và gọi `openclaw_test_state_create <label> <scenario>` trong từng flow. Các caller cấp thấp hơn có thể dùng `scripts/lib/openclaw-test-state.mjs shell --label <name> --scenario <name>` cho một snippet shell trong container, hoặc `node scripts/lib/openclaw-test-state.mjs -- create --label <name> --scenario <name> --env-file <path> --json` cho một tệp env host có thể source. Dấu `--` trước `create` ngăn các runtime Node mới hơn coi `--env-file` là một cờ Node. Các làn Docker/Bash khởi chạy Gateway có thể source `scripts/lib/openclaw-e2e-instance.sh` bên trong container để phân giải entrypoint, khởi động OpenAI giả lập, khởi chạy Gateway foreground/background, probe readiness, xuất env trạng thái, dump log, và dọn dẹp tiến trình.
+- Các lần chạy shard đầy đủ, extension, và include-pattern cập nhật dữ liệu thời gian cục bộ trong `.artifacts/vitest-shard-timings.json`; các lần chạy whole-config sau đó dùng những thời gian này để cân bằng shard chậm và nhanh. Các shard CI include-pattern nối tên shard vào khóa thời gian, giúp thời gian shard đã lọc vẫn hiển thị mà không thay thế dữ liệu thời gian whole-config. Đặt `OPENCLAW_TEST_PROJECTS_TIMINGS=0` để bỏ qua artifact thời gian cục bộ.
+- Một số tệp kiểm thử `plugin-sdk` và `commands` được chọn hiện định tuyến qua các làn nhẹ chuyên dụng chỉ giữ `test/setup.ts`, để các ca nặng về runtime ở lại làn hiện có của chúng.
+- Các tệp nguồn có kiểm thử cùng cấp ánh xạ tới tệp cùng cấp đó trước khi fallback về các glob thư mục rộng hơn. Các chỉnh sửa helper dưới `src/channels/plugins/contracts/test-helpers`, `src/plugin-sdk/test-helpers`, và `src/plugins/contracts` dùng đồ thị import cục bộ để chạy các kiểm thử import chúng thay vì chạy rộng mọi shard khi đường dẫn dependency chính xác.
+- `auto-reply` nay cũng tách thành ba config chuyên dụng (`core`, `top-level`, `reply`) để harness reply không lấn át các kiểm thử trạng thái/token/helper top-level nhẹ hơn.
+- Config Vitest cơ sở nay mặc định là `pool: "threads"` và `isolate: false`, với runner không cô lập dùng chung được bật trên các config trong repo.
 - `pnpm test:channels` chạy `vitest.channels.config.ts`.
-- `pnpm test:extensions` và `pnpm test extensions` chạy tất cả shard plugin. Các plugin kênh nặng, plugin trình duyệt và OpenAI chạy như shard chuyên dụng; các nhóm plugin khác vẫn được gom lô. Dùng `pnpm test extensions/<id>` cho một lane plugin tích hợp sẵn.
-- `pnpm test:perf:imports`: bật báo cáo thời lượng import + phân tích import của Vitest, trong khi vẫn dùng định tuyến lane có phạm vi cho các mục tiêu tệp/thư mục tường minh.
-- `pnpm test:perf:imports:changed`: profiling import tương tự, nhưng chỉ cho các tệp đã thay đổi kể từ `origin/main`.
-- `pnpm test:perf:changed:bench -- --ref <git-ref>` benchmark đường dẫn changed-mode đã định tuyến so với lần chạy root-project native cho cùng một diff git đã commit.
+- `pnpm test:extensions` và `pnpm test extensions` chạy mọi shard extension/plugin. Các plugin kênh nặng, plugin trình duyệt, và OpenAI chạy như shard chuyên dụng; các nhóm plugin khác vẫn được gom lô. Dùng `pnpm test extensions/<id>` cho một làn plugin bundled.
+- `pnpm test:perf:imports`: bật báo cáo thời lượng import + phân tích import của Vitest, trong khi vẫn dùng định tuyến làn theo phạm vi cho các mục tiêu tệp/thư mục rõ ràng.
+- `pnpm test:perf:imports:changed`: cùng profiling import, nhưng chỉ cho các tệp đã thay đổi kể từ `origin/main`.
+- `pnpm test:perf:changed:bench -- --ref <git-ref>` benchmark đường dẫn changed-mode đã định tuyến so với lần chạy root-project native cho cùng diff git đã commit.
 - `pnpm test:perf:changed:bench -- --worktree` benchmark tập thay đổi worktree hiện tại mà không cần commit trước.
-- `pnpm test:perf:profile:main`: ghi một CPU profile cho main thread của Vitest (`.artifacts/vitest-main-profile`).
-- `pnpm test:perf:profile:runner`: ghi CPU + heap profile cho runner đơn vị (`.artifacts/vitest-runner-profile`).
-- `pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json`: chạy tuần tự mọi cấu hình lá Vitest full-suite và ghi dữ liệu thời lượng theo nhóm cùng các artifact JSON/log theo từng cấu hình. Test Performance Agent dùng dữ liệu này làm baseline trước khi thử sửa các kiểm thử chậm.
+- `pnpm test:perf:profile:main`: ghi CPU profile cho thread chính của Vitest (`.artifacts/vitest-main-profile`).
+- `pnpm test:perf:profile:runner`: ghi CPU + heap profile cho unit runner (`.artifacts/vitest-runner-profile`).
+- `pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json`: chạy tuần tự mọi config lá Vitest full-suite và ghi dữ liệu thời lượng theo nhóm cùng các artifact JSON/log theo từng config. Test Performance Agent dùng dữ liệu này làm baseline trước khi thử sửa các kiểm thử chậm.
 - `pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json`: so sánh các báo cáo theo nhóm sau một thay đổi tập trung vào hiệu năng.
 - Tích hợp Gateway: bật tùy chọn qua `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` hoặc `pnpm test:gateway`.
-- `pnpm test:e2e`: Chạy các kiểm thử smoke end-to-end Gateway (ghép cặp nhiều phiên bản WS/HTTP/node). Mặc định dùng `threads` + `isolate: false` với worker thích ứng trong `vitest.e2e.config.ts`; tinh chỉnh bằng `OPENCLAW_E2E_WORKERS=<n>` và đặt `OPENCLAW_E2E_VERBOSE=1` để có log chi tiết.
-- `pnpm test:live`: Chạy kiểm thử live của provider (minimax/zai). Yêu cầu khóa API và `LIVE=1` (hoặc `*_LIVE_TEST=1` theo từng provider) để bỏ skip.
-- `pnpm test:docker:all`: Build image live-test dùng chung, đóng gói OpenClaw một lần thành npm tarball, build/tái sử dụng một image runner Node/Git tối giản cùng một image chức năng cài tarball đó vào `/app`, rồi chạy các lane smoke Docker với `OPENCLAW_SKIP_DOCKER_BUILD=1` qua một scheduler có trọng số. Image tối giản (`OPENCLAW_DOCKER_E2E_BARE_IMAGE`) được dùng cho các lane installer/update/plugin-dependency; các lane này mount tarball đã build sẵn thay vì dùng nguồn repo được sao chép. Image chức năng (`OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`) được dùng cho các lane chức năng built-app thông thường. `scripts/package-openclaw-for-docker.mjs` là trình đóng gói package local/CI duy nhất và xác thực tarball cùng `dist/postinstall-inventory.json` trước khi Docker tiêu thụ. Định nghĩa lane Docker nằm trong `scripts/lib/docker-e2e-scenarios.mjs`; logic planner nằm trong `scripts/lib/docker-e2e-plan.mjs`; `scripts/test-docker-all.mjs` thực thi plan đã chọn. `node scripts/test-docker-all.mjs --plan-json` phát ra plan CI do scheduler sở hữu cho các lane được chọn, loại image, nhu cầu package/live-image, kịch bản trạng thái và kiểm tra credential mà không build hoặc chạy Docker. `OPENCLAW_DOCKER_ALL_PARALLELISM=<n>` điều khiển slot tiến trình và mặc định là 10; `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM=<n>` điều khiển tail pool nhạy với provider và mặc định là 10. Giới hạn lane nặng mặc định là `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` và `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; giới hạn provider mặc định là một lane nặng cho mỗi provider qua `OPENCLAW_DOCKER_ALL_LIVE_CLAUDE_LIMIT=4`, `OPENCLAW_DOCKER_ALL_LIVE_CODEX_LIMIT=4` và `OPENCLAW_DOCKER_ALL_LIVE_GEMINI_LIMIT=4`. Dùng `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` hoặc `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` cho các host lớn hơn. Nếu một lane vượt quá trọng số hiệu dụng hoặc giới hạn tài nguyên trên host có mức song song thấp, nó vẫn có thể bắt đầu từ một pool trống và sẽ chạy một mình cho đến khi giải phóng dung lượng. Mặc định, thời điểm bắt đầu lane được giãn cách 2 giây để tránh bão tạo của daemon Docker cục bộ; ghi đè bằng `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=<ms>`. Runner mặc định preflight Docker, dọn các container E2E OpenClaw cũ, phát trạng thái lane đang hoạt động mỗi 30 giây, chia sẻ cache công cụ CLI provider giữa các lane tương thích, thử lại lỗi provider live tạm thời một lần theo mặc định (`OPENCLAW_DOCKER_ALL_LIVE_RETRIES=<n>`) và lưu thời gian lane trong `.artifacts/docker-tests/lane-timings.json` để sắp xếp dài nhất trước trong các lần chạy sau. Dùng `OPENCLAW_DOCKER_ALL_DRY_RUN=1` để in manifest lane mà không chạy Docker, `OPENCLAW_DOCKER_ALL_STATUS_INTERVAL_MS=<ms>` để tinh chỉnh đầu ra trạng thái, hoặc `OPENCLAW_DOCKER_ALL_TIMINGS=0` để tắt tái sử dụng thời gian. Dùng `OPENCLAW_DOCKER_ALL_LIVE_MODE=skip` chỉ cho các lane tất định/cục bộ hoặc `OPENCLAW_DOCKER_ALL_LIVE_MODE=only` chỉ cho các lane provider live; alias package là `pnpm test:docker:local:all` và `pnpm test:docker:live:all`. Chế độ chỉ live hợp nhất các lane live main và tail vào một pool dài nhất trước để các bucket provider có thể đóng gói công việc Claude, Codex và Gemini cùng nhau. Runner dừng lập lịch các lane pooled mới sau lỗi đầu tiên trừ khi đặt `OPENCLAW_DOCKER_ALL_FAIL_FAST=0`, và mỗi lane có timeout dự phòng 120 phút có thể ghi đè bằng `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; các lane live/tail được chọn dùng giới hạn chặt hơn theo từng lane. Các lệnh thiết lập Docker backend CLI có timeout riêng qua `OPENCLAW_LIVE_CLI_BACKEND_SETUP_TIMEOUT_SECONDS` (mặc định 180). Log theo từng lane, `summary.json`, `failures.json` và thời gian theo phase được ghi dưới `.artifacts/docker-tests/<run-id>/`; dùng `pnpm test:docker:timings <summary.json>` để kiểm tra các lane chậm và `pnpm test:docker:rerun <run-id|summary.json|failures.json>` để in các lệnh chạy lại có mục tiêu, chi phí thấp.
-- `pnpm test:docker:browser-cdp-snapshot`: Build một container E2E nguồn dựa trên Chromium, khởi động CDP thô cùng một Gateway biệt lập, chạy `browser doctor --deep` và xác minh snapshot vai trò CDP bao gồm URL liên kết, phần tử có thể nhấp được đẩy lên từ con trỏ, tham chiếu iframe và metadata frame.
-- Probe Docker live backend CLI có thể chạy như các lane tập trung, ví dụ `pnpm test:docker:live-cli-backend:codex`, `pnpm test:docker:live-cli-backend:codex:resume` hoặc `pnpm test:docker:live-cli-backend:codex:mcp`. Claude và Gemini có các alias `:resume` và `:mcp` tương ứng.
-- `pnpm test:docker:openwebui`: Khởi động OpenClaw + Open WebUI trong Docker, đăng nhập qua Open WebUI, kiểm tra `/api/models`, rồi chạy một cuộc trò chuyện được proxy thật qua `/api/chat/completions`. Yêu cầu một khóa mô hình live dùng được (ví dụ OpenAI trong `~/.profile`), kéo một image Open WebUI bên ngoài và không được kỳ vọng ổn định trong CI như các bộ unit/e2e thông thường.
-- `pnpm test:docker:mcp-channels`: Khởi động một container Gateway đã seed và một container client thứ hai spawn `openclaw mcp serve`, rồi xác minh khám phá cuộc hội thoại đã định tuyến, đọc transcript, metadata tệp đính kèm, hành vi hàng đợi sự kiện live, định tuyến gửi outbound và thông báo kênh + quyền kiểu Claude qua bridge stdio thật. Assertion thông báo Claude đọc trực tiếp các frame MCP stdio thô để smoke phản ánh đúng những gì bridge thực sự phát ra.
+- `pnpm test:e2e`: Chạy các kiểm thử smoke end-to-end Gateway (ghép cặp multi-instance WS/HTTP/node). Mặc định dùng `threads` + `isolate: false` với worker thích ứng trong `vitest.e2e.config.ts`; tinh chỉnh bằng `OPENCLAW_E2E_WORKERS=<n>` và đặt `OPENCLAW_E2E_VERBOSE=1` để có log chi tiết.
+- `pnpm test:live`: Chạy kiểm thử live provider (minimax/zai). Cần API key và `LIVE=1` (hoặc `*_LIVE_TEST=1` riêng theo provider) để bỏ skip.
+- `pnpm test:docker:all`: Build image live-test dùng chung, pack OpenClaw một lần dưới dạng npm tarball, build/tái sử dụng một image runner Node/Git trống cùng một image chức năng cài tarball đó vào `/app`, rồi chạy các làn smoke Docker với `OPENCLAW_SKIP_DOCKER_BUILD=1` qua một scheduler có trọng số. Image trống (`OPENCLAW_DOCKER_E2E_BARE_IMAGE`) được dùng cho các làn installer/update/plugin-dependency; các làn đó mount tarball đã build sẵn thay vì dùng nguồn repo đã sao chép. Image chức năng (`OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`) được dùng cho các làn chức năng ứng dụng đã build thông thường. `scripts/package-openclaw-for-docker.mjs` là packer package cục bộ/CI duy nhất và xác thực tarball cùng `dist/postinstall-inventory.json` trước khi Docker tiêu thụ nó. Định nghĩa làn Docker nằm trong `scripts/lib/docker-e2e-scenarios.mjs`; logic planner nằm trong `scripts/lib/docker-e2e-plan.mjs`; `scripts/test-docker-all.mjs` thực thi plan đã chọn. `node scripts/test-docker-all.mjs --plan-json` phát plan CI do scheduler sở hữu cho các làn, loại image, nhu cầu package/live-image, kịch bản trạng thái, và kiểm tra credential đã chọn mà không build hay chạy Docker. `OPENCLAW_DOCKER_ALL_PARALLELISM=<n>` điều khiển slot tiến trình và mặc định là 10; `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM=<n>` điều khiển tail pool nhạy với provider và mặc định là 10. Giới hạn làn nặng mặc định là `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10`, và `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; giới hạn provider mặc định là một làn nặng cho mỗi provider qua `OPENCLAW_DOCKER_ALL_LIVE_CLAUDE_LIMIT=4`, `OPENCLAW_DOCKER_ALL_LIVE_CODEX_LIMIT=4`, và `OPENCLAW_DOCKER_ALL_LIVE_GEMINI_LIMIT=4`. Dùng `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` hoặc `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` cho các host lớn hơn. Nếu một làn vượt quá giới hạn trọng số hoặc tài nguyên hiệu dụng trên một host có độ song song thấp, nó vẫn có thể bắt đầu từ pool trống và sẽ chạy một mình cho đến khi giải phóng capacity. Việc khởi động làn được giãn cách 2 giây theo mặc định để tránh bão tạo local Docker daemon; ghi đè bằng `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=<ms>`. Runner preflight Docker theo mặc định, dọn các container OpenClaw E2E cũ, phát trạng thái làn đang hoạt động mỗi 30 giây, chia sẻ cache công cụ CLI provider giữa các làn tương thích, thử lại lỗi live-provider tạm thời một lần theo mặc định (`OPENCLAW_DOCKER_ALL_LIVE_RETRIES=<n>`), và lưu thời gian làn trong `.artifacts/docker-tests/lane-timings.json` để sắp xếp longest-first trong các lần chạy sau. Dùng `OPENCLAW_DOCKER_ALL_DRY_RUN=1` để in manifest làn mà không chạy Docker, `OPENCLAW_DOCKER_ALL_STATUS_INTERVAL_MS=<ms>` để tinh chỉnh output trạng thái, hoặc `OPENCLAW_DOCKER_ALL_TIMINGS=0` để tắt tái sử dụng thời gian. Dùng `OPENCLAW_DOCKER_ALL_LIVE_MODE=skip` chỉ cho các làn xác định/cục bộ hoặc `OPENCLAW_DOCKER_ALL_LIVE_MODE=only` chỉ cho các làn live-provider; alias package là `pnpm test:docker:local:all` và `pnpm test:docker:live:all`. Chế độ live-only gộp các làn live chính và tail vào một pool longest-first để các bucket provider có thể đóng gói công việc Claude, Codex, và Gemini cùng nhau. Runner dừng lập lịch các làn pooled mới sau lỗi đầu tiên trừ khi đặt `OPENCLAW_DOCKER_ALL_FAIL_FAST=0`, và mỗi làn có timeout fallback 120 phút có thể ghi đè bằng `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; một số làn live/tail được chọn dùng giới hạn theo làn chặt hơn. Các lệnh thiết lập Docker backend CLI có timeout riêng qua `OPENCLAW_LIVE_CLI_BACKEND_SETUP_TIMEOUT_SECONDS` (mặc định 180). Log theo từng làn, `summary.json`, `failures.json`, và thời gian pha được ghi dưới `.artifacts/docker-tests/<run-id>/`; dùng `pnpm test:docker:timings <summary.json>` để kiểm tra các làn chậm và `pnpm test:docker:rerun <run-id|summary.json|failures.json>` để in các lệnh chạy lại nhắm mục tiêu rẻ.
+- `pnpm test:docker:browser-cdp-snapshot`: Build một container E2E nguồn dựa trên Chromium, khởi động CDP raw cùng một Gateway cô lập, chạy `browser doctor --deep`, và xác minh snapshot vai trò CDP bao gồm URL liên kết, phần tử có thể bấm được thăng cấp từ con trỏ, ref iframe, và metadata frame.
+- Probe Docker live backend CLI có thể chạy dưới dạng các làn tập trung, ví dụ `pnpm test:docker:live-cli-backend:codex`, `pnpm test:docker:live-cli-backend:codex:resume`, hoặc `pnpm test:docker:live-cli-backend:codex:mcp`. Claude và Gemini có alias `:resume` và `:mcp` tương ứng.
+- `pnpm test:docker:openwebui`: Khởi động OpenClaw + Open WebUI trong Docker, đăng nhập qua Open WebUI, kiểm tra `/api/models`, rồi chạy một cuộc chat được proxy thật qua `/api/chat/completions`. Cần một khóa mô hình live dùng được (ví dụ OpenAI trong `~/.profile`), pull một image Open WebUI bên ngoài, và không được kỳ vọng ổn định trong CI như các bộ unit/e2e thông thường.
+- `pnpm test:docker:mcp-channels`: Khởi động một container Gateway đã seed và một container client thứ hai spawn `openclaw mcp serve`, rồi xác minh khám phá hội thoại đã định tuyến, đọc transcript, metadata attachment, hành vi hàng đợi sự kiện live, định tuyến gửi outbound, và thông báo kênh + quyền kiểu Claude qua cầu nối stdio thật. Assertion thông báo Claude đọc trực tiếp các frame MCP stdio raw để smoke phản ánh đúng thứ cầu nối thực sự phát ra.
+- `pnpm test:docker:upgrade-survivor`: Cài đặt tarball OpenClaw đã được đóng gói lên một fixture người dùng cũ đang ở trạng thái bẩn, chạy cập nhật package cùng với doctor không tương tác mà không có khóa nhà cung cấp hoặc kênh live, sau đó khởi động một Gateway loopback và kiểm tra rằng các agent, cấu hình kênh, danh sách cho phép Plugin, tệp workspace/session, trạng thái runtime-deps của Plugin đã cũ, quá trình khởi động và trạng thái RPC vẫn tồn tại.
 
-## Gate PR cục bộ
+## Cổng PR cục bộ
 
 Để chạy các kiểm tra land/gate PR cục bộ, hãy chạy:
 
@@ -61,29 +62,29 @@ x-i18n:
 - `pnpm test`
 - `pnpm check:docs`
 
-Nếu `pnpm test` thất bại không ổn định trên một máy chủ đang tải cao, hãy chạy lại một lần trước khi coi đó là lỗi hồi quy, rồi cô lập bằng `pnpm test <path/to/test>`. Với các máy chủ bị hạn chế bộ nhớ, hãy dùng:
+Nếu `pnpm test` bị flaky trên một máy chủ đang tải nặng, hãy chạy lại một lần trước khi xem đó là hồi quy, rồi cô lập bằng `pnpm test <path/to/test>`. Với các máy chủ hạn chế bộ nhớ, hãy dùng:
 
 - `OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test`
 - `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/tmp/openclaw-vitest-cache pnpm test:changed`
 
-## Benchmark độ trễ mô hình (khóa cục bộ)
+## Bench độ trễ mô hình (khóa cục bộ)
 
-Tập lệnh: [`scripts/bench-model.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-model.ts)
+Script: [`scripts/bench-model.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-model.ts)
 
 Cách dùng:
 
 - `source ~/.profile && pnpm tsx scripts/bench-model.ts --runs 10`
-- Biến môi trường tùy chọn: `MINIMAX_API_KEY`, `MINIMAX_BASE_URL`, `MINIMAX_MODEL`, `ANTHROPIC_API_KEY`
-- Lời nhắc mặc định: “Trả lời bằng một từ duy nhất: ok. Không dùng dấu câu hoặc văn bản bổ sung.”
+- Env tùy chọn: `MINIMAX_API_KEY`, `MINIMAX_BASE_URL`, `MINIMAX_MODEL`, `ANTHROPIC_API_KEY`
+- Prompt mặc định: “Trả lời bằng một từ duy nhất: ok. Không có dấu câu hoặc văn bản bổ sung.”
 
 Lần chạy gần nhất (2025-12-31, 20 lần chạy):
 
 - minimax trung vị 1279ms (tối thiểu 1114, tối đa 2431)
 - opus trung vị 2454ms (tối thiểu 1224, tối đa 3170)
 
-## Benchmark khởi động CLI
+## Bench khởi động CLI
 
-Tập lệnh: [`scripts/bench-cli-startup.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-cli-startup.ts)
+Script: [`scripts/bench-cli-startup.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-cli-startup.ts)
 
 Cách dùng:
 
@@ -103,21 +104,21 @@ Cách dùng:
 - `pnpm tsx scripts/bench-cli-startup.ts --preset real --cpu-prof-dir .artifacts/cli-cpu`
 - `pnpm tsx scripts/bench-cli-startup.ts --json`
 
-Các cấu hình đặt sẵn:
+Bộ thiết lập sẵn:
 
 - `startup`: `--version`, `--help`, `health`, `health --json`, `status --json`, `status`
 - `real`: `health`, `status`, `status --json`, `sessions`, `sessions --json`, `tasks --json`, `tasks list --json`, `tasks audit --json`, `agents list --json`, `gateway status`, `gateway status --json`, `gateway health --json`, `config get gateway.port`
-- `all`: cả hai cấu hình đặt sẵn
+- `all`: cả hai bộ thiết lập sẵn
 
-Đầu ra bao gồm `sampleCount`, trung bình, p50, p95, tối thiểu/tối đa, phân bố mã thoát/tín hiệu và tóm tắt RSS tối đa cho từng lệnh. `--cpu-prof-dir` / `--heap-prof-dir` tùy chọn ghi hồ sơ V8 cho mỗi lần chạy để phép đo thời gian và việc thu thập hồ sơ dùng cùng một bộ công cụ.
+Đầu ra bao gồm `sampleCount`, trung bình, p50, p95, tối thiểu/tối đa, phân bố mã thoát/tín hiệu, và tóm tắt RSS tối đa cho từng lệnh. `--cpu-prof-dir` / `--heap-prof-dir` tùy chọn ghi các hồ sơ V8 cho mỗi lần chạy để việc đo thời gian và thu thập hồ sơ dùng cùng một harness.
 
 Quy ước đầu ra đã lưu:
 
-- `pnpm test:startup:bench:smoke` ghi artifact smoke được nhắm mục tiêu tại `.artifacts/cli-startup-bench-smoke.json`
+- `pnpm test:startup:bench:smoke` ghi artifact smoke mục tiêu tại `.artifacts/cli-startup-bench-smoke.json`
 - `pnpm test:startup:bench:save` ghi artifact bộ đầy đủ tại `.artifacts/cli-startup-bench-all.json` bằng `runs=5` và `warmup=1`
-- `pnpm test:startup:bench:update` làm mới fixture baseline đã được đưa vào repo tại `test/fixtures/cli-startup-bench.json` bằng `runs=5` và `warmup=1`
+- `pnpm test:startup:bench:update` làm mới fixture baseline đã đưa vào repo tại `test/fixtures/cli-startup-bench.json` bằng `runs=5` và `warmup=1`
 
-Fixture đã được đưa vào repo:
+Fixture đã đưa vào repo:
 
 - `test/fixtures/cli-startup-bench.json`
 - Làm mới bằng `pnpm test:startup:bench:update`
@@ -125,19 +126,19 @@ Fixture đã được đưa vào repo:
 
 ## Onboarding E2E (Docker)
 
-Docker là tùy chọn; mục này chỉ cần cho các kiểm thử smoke onboarding trong container.
+Docker là tùy chọn; phần này chỉ cần cho các kiểm thử smoke onboarding trong container.
 
-Luồng khởi động nguội đầy đủ trong một container Linux sạch:
+Luồng khởi động lạnh đầy đủ trong một container Linux sạch:
 
 ```bash
 scripts/e2e/onboard-docker.sh
 ```
 
-Tập lệnh này điều khiển trình hướng dẫn tương tác qua pseudo-tty, xác minh các tệp cấu hình/không gian làm việc/phiên, sau đó khởi động Gateway và chạy `openclaw health`.
+Script này điều khiển trình hướng dẫn tương tác qua pseudo-tty, xác minh các tệp cấu hình/workspace/session, rồi khởi động Gateway và chạy `openclaw health`.
 
 ## Smoke nhập QR (Docker)
 
-Đảm bảo helper runtime QR được bảo trì tải được dưới các runtime Docker Node được hỗ trợ (mặc định Node 24, tương thích Node 22):
+Đảm bảo helper runtime QR được duy trì tải được dưới các runtime Docker Node được hỗ trợ (Node 24 mặc định, tương thích Node 22):
 
 ```bash
 pnpm test:docker:qr
@@ -146,4 +147,4 @@ pnpm test:docker:qr
 ## Liên quan
 
 - [Kiểm thử](/vi/help/testing)
-- [Kiểm thử live](/vi/help/testing-live)
+- [Kiểm thử trực tiếp](/vi/help/testing-live)