docs: rewrite CI docs for simplified 4-workflow system

Remove all references to deleted workflows (ci-run.yml, CI Required Gate,
sec-audit, pub-docker-img, pub-release, pub-homebrew-core, pr-intake-checks,
pr-labeler, pr-auto-response, pr-check-stale, pr-check-status, pr-label-policy,
workflow-sanity, main-promotion-gate, sec-codeql, sec-vorpal, etc.).

Rewrite docs to match the current 4 workflows:
- ci.yml (PR checks: test + build)
- release.yml (automatic beta release on push to master)
- ci-full.yml (manual full cross-platform build matrix)
- promote-release.yml (manual stable release)

Files rewritten:
- docs/ci-map.md — complete rewrite for current workflows
- docs/release-process.md — new two-tier release model (beta/stable)
- .github/workflows/main-branch-flow.md — simplified delivery flows
- .github/workflows/README.md — removed deleted helper scripts

Files updated (stale CI references removed):
- docs/pr-workflow.md
- docs/reviewer-playbook.md
- CONTRIBUTING.md
- Vietnamese locale sync: docs/vi/ and docs/i18n/vi/ (ci-map, pr-workflow,
  release-process, reviewer-playbook)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

.github/workflows/README.md

@@ -10,21 +10,15 @@ Subdirectories are not valid locations for workflow entry files.
 Repository convention:
 
 1. Keep runnable workflow entry files at `.github/workflows/` root.
-2. Keep workflow-only helper scripts under `.github/workflows/scripts/`.
-3. Keep cross-tooling/local CI scripts under `scripts/ci/` when they are used outside Actions.
+2. Keep cross-tooling/local CI scripts under `scripts/ci/` when they are used outside Actions.
 
 Workflow behavior documentation in this directory:
 
-- `.github/workflows/main-branch-flow.md`
+- `.github/workflows/master-branch-flow.md`
 
-Current workflow helper scripts:
+Current workflows:
 
-- `.github/workflows/scripts/ci_workflow_owner_approval.js`
-- `.github/workflows/scripts/ci_license_file_owner_guard.js`
-- `.github/workflows/scripts/lint_feedback.js`
-- `.github/workflows/scripts/pr_auto_response_contributor_tier.js`
-- `.github/workflows/scripts/pr_auto_response_labeled_routes.js`
-- `.github/workflows/scripts/pr_check_status_nudge.js`
-- `.github/workflows/scripts/pr_intake_checks.js`
-- `.github/workflows/scripts/pr_labeler.js`
-- `.github/workflows/scripts/test_benchmarks_pr_comment.js`
+- `.github/workflows/ci.yml` — PR checks (test + build)
+- `.github/workflows/ci-full.yml` — manual full cross-platform build matrix
+- `.github/workflows/release.yml` — automatic beta release on push to `master`
+- `.github/workflows/promote-release.yml` — manual stable release

.github/workflows/main-branch-flow.md

@@ -1,6 +1,6 @@
-# Main Branch Delivery Flows
+# Master Branch Delivery Flows
 
-This document explains what runs when code is proposed to `dev`, promoted to `main`, and released.
+This document explains what runs when code is proposed to `master`, merged, and released.
 
 Use this with:
 
@@ -10,230 +10,74 @@ Use this with:
 
 ## Event Summary
 
-| Event | Main workflows |
+| Event | Workflow |
 | --- | --- |
-| PR activity (`pull_request_target`) | `pr-intake-checks.yml`, `pr-labeler.yml`, `pr-auto-response.yml` |
-| PR activity (`pull_request`) | `ci-run.yml`, `sec-audit.yml`, `main-promotion-gate.yml` (for `main` PRs), plus path-scoped workflows |
-| Push to `dev`/`main` | `ci-run.yml`, `sec-audit.yml`, plus path-scoped workflows |
-| Tag push (`v*`) | `pub-release.yml` publish mode, `pub-docker-img.yml` publish job |
-| Scheduled/manual | `pub-release.yml` verification mode, `pub-homebrew-core.yml` (manual), `sec-codeql.yml`, `feature-matrix.yml`, `test-fuzz.yml`, `pr-check-stale.yml`, `pr-check-status.yml`, `sync-contributors.yml`, `test-benchmarks.yml`, `test-e2e.yml` |
-
-## Runtime and Docker Matrix
-
-Observed averages below are from recent completed runs (sampled from GitHub Actions on February 17, 2026). Values are directional, not SLA.
-
-| Workflow | Typical trigger in main flow | Avg runtime | Docker build? | Docker run? | Docker push? |
-| --- | --- | ---:| --- | --- | --- |
-| `pr-intake-checks.yml` | PR open/update (`pull_request_target`) | 14.5s | No | No | No |
-| `pr-labeler.yml` | PR open/update (`pull_request_target`) | 53.7s | No | No | No |
-| `pr-auto-response.yml` | PR/issue automation | 24.3s | No | No | No |
-| `ci-run.yml` | PR + push to `dev`/`main` | 74.7s | No | No | No |
-| `sec-audit.yml` | PR + push to `dev`/`main` | 127.2s | No | No | No |
-| `workflow-sanity.yml` | Workflow-file changes | 34.2s | No | No | No |
-| `pr-label-policy-check.yml` | Label policy/automation changes | 14.7s | No | No | No |
-| `pub-docker-img.yml` (`pull_request`) | Docker build-input PR changes | 240.4s | Yes | Yes | No |
-| `pub-docker-img.yml` (`push`) | tag push `v*` | 139.9s | Yes | No | Yes |
-| `pub-release.yml` | Tag push `v*` (publish) + manual/scheduled verification (no publish) | N/A in recent sample | No | No | No |
-| `pub-homebrew-core.yml` | Manual workflow dispatch only | N/A in recent sample | No | No | No |
-
-Notes:
-
-1. `pub-docker-img.yml` is the only workflow in the main PR/push path that builds Docker images.
-2. Container runtime verification (`docker run`) occurs in PR smoke only.
-3. Container registry push occurs on tag pushes (`v*`) only.
-4. `ci-run.yml` "Build (Smoke)" builds Rust binaries, not Docker images.
+| PR to `master` | `ci.yml` |
+| Push to `master` (merge) | `release.yml` (Beta Release) |
+| Manual dispatch | `ci-full.yml` (CI Full Matrix), `promote-release.yml` (Promote Release) |
 
 ## Step-By-Step
 
-### 1) PR from branch in this repository -> `dev`
+### 1) PR to `master`
 
-1. Contributor opens or updates PR against `dev`.
-2. `pull_request_target` automation runs (typical runtime):
-   - `pr-intake-checks.yml` posts intake warnings/errors.
-   - `pr-labeler.yml` sets size/risk/scope labels.
-   - `pr-auto-response.yml` runs first-interaction and label routes.
-3. `pull_request` CI workflows start:
-   - `ci-run.yml`
-   - `sec-audit.yml`
-   - path-scoped workflows if matching files changed:
-     - `pub-docker-img.yml` (Docker build-input paths only)
-     - `workflow-sanity.yml` (workflow files only)
-     - `pr-label-policy-check.yml` (label-policy files only)
-4. In `ci-run.yml`, `changes` computes:
-   - `docs_only`
-   - `docs_changed`
-   - `rust_changed`
-   - `workflow_changed`
-5. `build` runs for Rust-impacting changes.
-6. On PRs, full lint/test/docs checks run when PR has label `ci:full`:
-   - `lint`
-   - `lint-strict-delta`
-   - `test`
-   - `docs-quality`
-7. If `.github/workflows/**` changed, `workflow-owner-approval` must pass.
-8. If root license files (`LICENSE-APACHE`, `LICENSE-MIT`) changed, `license-file-owner-guard` allows only PR author `willsarg`.
-9. `lint-feedback` posts actionable comment if lint/docs gates fail.
-10. `CI Required Gate` aggregates results to final pass/fail.
-11. Maintainer merges PR once checks and review policy are satisfied.
-12. Merge emits a `push` event on `dev` (see scenario 4).
+1. Contributor opens or updates PR against `master`.
+2. `ci.yml` runs:
+   - `test` — runs `cargo nextest run --locked` with mold linker on Ubuntu.
+   - `build` — builds release binaries for `x86_64-unknown-linux-gnu` and `aarch64-apple-darwin`.
+3. Both jobs must pass for the PR to be mergeable.
+4. Maintainer merges PR once checks and review policy are satisfied.
 
-### 2) PR from fork -> `dev`
+### 2) Push to `master` (after merge)
 
-1. External contributor opens PR from `fork/<branch>` into `zeroclaw:dev`.
-2. Immediately on `opened`:
-   - `pull_request_target` workflows start with base-repo context and base-repo token:
-     - `pr-intake-checks.yml`
-     - `pr-labeler.yml`
-     - `pr-auto-response.yml`
-   - `pull_request` workflows are queued for the fork head commit:
-     - `ci-run.yml`
-     - `sec-audit.yml`
-     - path-scoped workflows (`pub-docker-img.yml`, `workflow-sanity.yml`, `pr-label-policy-check.yml`) if changed files match.
-3. Fork-specific permission behavior in `pull_request` workflows:
-   - token is restricted (read-focused), so jobs that try to write PR comments/status extras can be limited.
-   - secrets from the base repo are not exposed to fork PR `pull_request` jobs.
-4. Approval gate possibility:
-   - if Actions settings require maintainer approval for fork workflows, the `pull_request` run stays in `action_required`/waiting state until approved.
-5. Event fan-out after labeling:
-   - `pr-labeler.yml` and manual label changes emit `labeled`/`unlabeled` events.
-   - those events retrigger `pull_request_target` automation (`pr-labeler.yml` and `pr-auto-response.yml`), creating extra run volume/noise.
-6. When contributor pushes new commits to fork branch (`synchronize`):
-   - reruns: `pr-intake-checks.yml`, `pr-labeler.yml`, `ci-run.yml`, `sec-audit.yml`, and matching path-scoped PR workflows.
-   - does not rerun `pr-auto-response.yml` unless label/open events occur.
-7. `ci-run.yml` execution details for fork PR:
-   - `changes` computes `docs_only`, `docs_changed`, `rust_changed`, `workflow_changed`.
-   - `build` runs for Rust-impacting changes.
-   - `lint`/`lint-strict-delta`/`test`/`docs-quality` run on PR when `ci:full` label exists.
-   - `workflow-owner-approval` runs when `.github/workflows/**` changed.
-   - `CI Required Gate` emits final pass/fail for the PR head.
-8. Fork PR merge blockers to check first when diagnosing stalls:
-   - run approval pending for fork workflows.
-   - `workflow-owner-approval` failing on workflow-file changes.
-   - `license-file-owner-guard` failing when root license files are modified by non-owner PR author.
-   - `CI Required Gate` failure caused by upstream jobs.
-   - repeated `pull_request_target` reruns from label churn causing noisy signals.
-9. After merge, normal `push` workflows on `dev` execute (scenario 4).
+1. Merged commit reaches `master`.
+2. `release.yml` (Beta Release) runs automatically:
+   - Computes beta version tag: `vX.Y.Z-beta.<run_number>`.
+   - Builds 5-target release matrix (linux x86_64 + aarch64, macOS x86_64 + aarch64, Windows x86_64).
+   - Packages archives with SHA256SUMS.
+   - Creates GitHub pre-release.
+   - Builds and pushes multi-platform Docker image to GHCR (`beta` + version tag).
 
-### 3) Promotion PR `dev` -> `main`
+### 3) Stable release (manual)
 
-1. Maintainer opens PR with head `dev` and base `main`.
-2. `main-promotion-gate.yml` runs and fails unless PR author is `willsarg` or `theonlyhennygod`.
-3. `main-promotion-gate.yml` also fails if head repo/branch is not `<this-repo>:dev`.
-4. `ci-run.yml` and `sec-audit.yml` run on the promotion PR.
-5. Maintainer merges PR once checks and review policy pass.
-6. Merge emits a `push` event on `main`.
-
-### 4) Push to `dev` or `main` (including after merge)
-
-1. Commit reaches `dev` or `main` (usually from a merged PR).
-2. `ci-run.yml` runs on `push`.
-3. `sec-audit.yml` runs on `push`.
-4. Path-filtered workflows run only if touched files match their filters.
-5. In `ci-run.yml`, push behavior differs from PR behavior:
-   - Rust path: `lint`, `lint-strict-delta`, `test`, `build` are expected.
-   - Docs/non-rust paths: fast-path behavior applies.
-6. `CI Required Gate` computes overall push result.
-
-## Docker Publish Logic
-
-Workflow: `.github/workflows/pub-docker-img.yml`
-
-### PR behavior
-
-1. Triggered on `pull_request` to `dev` or `main` when Docker build-input paths change.
-2. Runs `PR Docker Smoke` job:
-   - Builds local smoke image with Blacksmith builder.
-   - Verifies container with `docker run ... --version`.
-3. Typical runtime in recent sample: ~240.4s.
-4. No registry push happens on PR events.
-
-### Push behavior
-
-1. `publish` job runs on tag pushes `v*` only.
-2. Workflow trigger includes semantic version tag pushes (`v*`) only.
-3. Login to `ghcr.io` uses `${{ github.actor }}` and `${{ secrets.GITHUB_TOKEN }}`.
-4. Tag computation includes semantic tag from pushed git tag (`vX.Y.Z`) + SHA tag.
-5. Multi-platform publish is used for tag pushes (`linux/amd64,linux/arm64`).
-6. Typical runtime in recent sample: ~139.9s.
-7. Result: pushed image tags under `ghcr.io/<owner>/<repo>`.
-
-Important: Docker publish now requires a `v*` tag push; regular `dev`/`main` branch pushes do not publish images.
-
-## Release Logic
-
-Workflow: `.github/workflows/pub-release.yml`
-
-1. Trigger modes:
-   - Tag push `v*` -> publish mode.
-   - Manual dispatch -> verification-only or publish mode (input-driven).
-   - Weekly schedule -> verification-only mode.
-2. `prepare` resolves release context (`release_ref`, `release_tag`, publish/draft mode) and validates manual publish inputs.
-   - publish mode enforces `release_tag` == `Cargo.toml` version at the tag commit.
-3. `build-release` builds matrix artifacts across Linux/macOS/Windows targets.
-4. `verify-artifacts` enforces presence of all expected archives before any publish attempt.
-5. In publish mode, workflow generates SBOM (`CycloneDX` + `SPDX`), `SHA256SUMS`, keyless cosign signatures, and verifies GHCR release-tag availability.
-6. In publish mode, workflow creates/updates the GitHub Release for the resolved tag and commit-ish.
-
-Manual Homebrew formula flow:
-
-1. Run `.github/workflows/pub-homebrew-core.yml` with `release_tag=vX.Y.Z`.
-2. Use `dry_run=true` first to validate formula patch and metadata.
-3. Use `dry_run=false` to push from bot fork and open `homebrew-core` PR.
-
-## Merge/Policy Notes
-
-1. Workflow-file changes (`.github/workflows/**`) activate owner-approval gate in `ci-run.yml`.
-2. PR lint/test strictness is intentionally controlled by `ci:full` label.
-3. `sec-audit.yml` runs on both PR and push, plus scheduled weekly.
-4. Some workflows are operational and non-merge-path (`pr-check-stale`, `pr-check-status`, `sync-contributors`, etc.).
-5. Workflow-specific JavaScript helpers are organized under `.github/workflows/scripts/`.
+1. Maintainer runs `promote-release.yml` via workflow dispatch with version input (e.g. `0.2.0`).
+2. Workflow validates version matches `Cargo.toml` and tag does not already exist.
+3. Builds same 5-target matrix as beta release.
+4. Creates GitHub stable release (non-pre-release) with archives + SHA256SUMS.
+5. Builds and pushes Docker image to GHCR (`latest` + version tag).
 
 ## Mermaid Diagrams
 
-### PR to Dev
+### PR and Merge Flow
 
 ```mermaid
 flowchart TD
-  A["PR opened or updated -> dev"] --> B["pull_request_target lane"]
-  B --> B1["pr-intake-checks.yml"]
-  B --> B2["pr-labeler.yml"]
-  B --> B3["pr-auto-response.yml"]
-  A --> C["pull_request CI lane"]
-  C --> C1["ci-run.yml"]
-  C --> C2["sec-audit.yml"]
-  C --> C3["pub-docker-img.yml (if Docker paths changed)"]
-  C --> C4["workflow-sanity.yml (if workflow files changed)"]
-  C --> C5["pr-label-policy-check.yml (if policy files changed)"]
-  C1 --> D["CI Required Gate"]
-  D --> E{"Checks + review policy pass?"}
-  E -->|No| F["PR stays open"]
-  E -->|Yes| G["Merge PR"]
-  G --> H["push event on dev"]
+  A["PR opened/updated → master"] --> B["ci.yml"]
+  B --> B1["test (cargo nextest)"]
+  B --> B2["build (linux + macOS)"]
+  B1 --> C{"Both pass?"}
+  B2 --> C
+  C -->|No| D["PR stays open"]
+  C -->|Yes| E["Merge PR"]
+  E --> F["push to master"]
+  F --> G["release.yml (Beta Release)"]
+  G --> G1["Build 5 targets"]
+  G1 --> G2["Publish GitHub pre-release"]
+  G1 --> G3["Push Docker image to GHCR"]
 ```
 
-### Promotion and Release
+### Stable Release Flow
 
 ```mermaid
 flowchart TD
-  D0["Commit reaches dev"] --> B0["ci-run.yml"]
-  D0 --> C0["sec-audit.yml"]
-  P["Promotion PR dev -> main"] --> PG["main-promotion-gate.yml"]
-  PG --> M["Merge to main"]
-  M --> A["Commit reaches main"]
-  A --> B["ci-run.yml"]
-  A --> C["sec-audit.yml"]
-  A --> D["path-scoped workflows (if matched)"]
-  T["Tag push v*"] --> R["pub-release.yml"]
-  W["Manual/Scheduled release verify"] --> R
-  T --> P["pub-docker-img.yml publish job"]
-  R --> R1["Artifacts + SBOM + checksums + signatures + GitHub Release"]
-  W --> R2["Verification build only (no GitHub Release publish)"]
-  P --> P1["Push ghcr image tags (version + sha)"]
+  M["Maintainer runs promote-release.yml"] --> V["Validate version + Cargo.toml"]
+  V --> B["Build 5 targets"]
+  B --> P["Publish GitHub stable release"]
+  B --> D["Push Docker image to GHCR (latest)"]
 ```
 
 ## Quick Troubleshooting
 
-1. Unexpected skipped jobs: inspect `scripts/ci/detect_change_scope.sh` outputs.
-2. Workflow-change PR blocked: verify `WORKFLOW_OWNER_LOGINS` and approvals.
-3. Fork PR appears stalled: check whether Actions run approval is pending.
-4. Docker not published: confirm a `v*` tag was pushed to the intended commit.
+1. **CI failing on PR:** check `test` and `build` jobs in `.github/workflows/ci.yml`.
+2. **Beta release failing:** check `.github/workflows/release.yml` job logs.
+3. **Stable release failing:** check `validate` job in `.github/workflows/promote-release.yml` for version mismatch.
+4. **Docker push failing:** check GHCR authentication and `docker` job logs in the release workflow.

CONTRIBUTING.md

@@ -194,7 +194,7 @@ To keep review throughput high without lowering quality, every PR should map to
 
 | Track | Typical scope | Required review depth |
 |---|---|---|
-| **Track A (Low risk)** | docs/tests/chore, isolated refactors, no security/runtime/CI impact | 1 maintainer review + green `CI Required Gate` |
+| **Track A (Low risk)** | docs/tests/chore, isolated refactors, no security/runtime/CI impact | 1 maintainer review + green CI checks (`test` + `build`) |
 | **Track B (Medium risk)** | providers/channels/memory/tools behavior changes | 1 subsystem-aware review + explicit validation evidence |
 | **Track C (High risk)** | `src/security/**`, `src/runtime/**`, `src/gateway/**`, `.github/workflows/**`, access-control boundaries | 2-pass review (fast triage + deep risk review), rollback plan required |
 
@@ -244,7 +244,7 @@ Before requesting review, ensure all of the following are true:
 
 A PR is merge-ready when:
 
-- `CI Required Gate` is green.
+- CI checks are green (`test` + `build` from `ci.yml`).
 - Required reviewers approved (including CODEOWNERS paths).
 - Risk level matches changed paths (`risk: low/medium/high`).
 - User-visible behavior, migration, and rollback notes are complete.
@@ -532,12 +532,10 @@ Recommended scope keys in commit titles:
 
 ## Maintainer Merge Policy
 
-- Require passing `CI Required Gate` before merge.
-- Require docs quality checks when docs are touched.
+- Require passing CI checks (`test` + `build`) before merge.
 - Require review approval for non-trivial changes.
 - Require CODEOWNERS review for protected paths.
-- Use risk labels to determine review depth, scope labels (`core`, `provider`, `channel`, `security`, etc.) to route ownership, and module labels (`<module>:<component>`, e.g. `channel:telegram`, `provider:kimi`, `tool:shell`) to route subsystem expertise.
-- Contributor tier labels are auto-applied on PRs and issues by merged PR count: `experienced contributor` (>=10), `principal contributor` (>=20), `distinguished contributor` (>=50). Treat them as read-only automation labels; manual edits are auto-corrected.
+- Use risk labels to determine review depth and scope labels to route ownership.
 - Prefer squash merge with conventional commit title.
 - Revert fast on regressions; re-land with tests.
 

docs/ci-map.md

@@ -2,128 +2,66 @@
 
 This document explains what each GitHub workflow does, when it runs, and whether it should block merges.
 
-For event-by-event delivery behavior across PR, merge, push, and release, see [`.github/workflows/main-branch-flow.md`](../.github/workflows/main-branch-flow.md).
+For event-by-event delivery behavior across PR, merge, push, and release, see [`.github/workflows/master-branch-flow.md`](../.github/workflows/master-branch-flow.md).
 
-## Merge-Blocking vs Optional
+## Workflows
 
-Merge-blocking checks should stay small and deterministic. Optional checks are useful for automation and maintenance, but should not block normal development.
+### CI (`.github/workflows/ci.yml`)
 
-### Merge-Blocking
+- **Trigger:** pull requests to `master`
+- **Purpose:** run tests and build release binaries on Linux and macOS
+- **Jobs:**
+    - `test` — `cargo nextest run --locked` with mold linker
+    - `build` — release build matrix (`x86_64-unknown-linux-gnu`, `aarch64-apple-darwin`)
+- **Merge gate:** both `test` and `build` must pass before merge
 
-- `.github/workflows/ci-run.yml` (`CI`)
-    - Purpose: Rust validation (`cargo fmt --all -- --check`, `cargo clippy --locked --all-targets -- -D clippy::correctness`, strict delta lint gate on changed Rust lines, `test`, release build smoke) + docs quality checks when docs change (`markdownlint` blocks only issues on changed lines; link check scans only links added on changed lines)
-    - Additional behavior: for Rust-impacting PRs and pushes, `CI Required Gate` requires `lint` + `test` + `build` (no PR build-only bypass)
-    - Additional behavior: PRs that change `.github/workflows/**` require at least one approving review from a login in `WORKFLOW_OWNER_LOGINS` (repository variable fallback: `theonlyhennygod,willsarg`)
-    - Additional behavior: PRs that change root license files (`LICENSE-APACHE`, `LICENSE-MIT`) must be authored by `willsarg`
-    - Additional behavior: lint gates run before `test`/`build`; when lint/docs gates fail on PRs, CI posts an actionable feedback comment with failing gate names and local fix commands
-    - Merge gate: `CI Required Gate`
-- `.github/workflows/workflow-sanity.yml` (`Workflow Sanity`)
-    - Purpose: lint GitHub workflow files (`actionlint`, tab checks)
-    - Recommended for workflow-changing PRs
-- `.github/workflows/pr-intake-checks.yml` (`PR Intake Checks`)
-    - Purpose: safe pre-CI PR checks (template completeness, added-line tabs/trailing-whitespace/conflict markers) with immediate sticky feedback comment
-- `.github/workflows/main-promotion-gate.yml` (`Main Promotion Gate`)
-    - Purpose: enforce stable-branch policy by allowing only `dev` -> `main` PR promotion authored by `willsarg` or `theonlyhennygod`
+### Beta Release (`.github/workflows/release.yml`)
 
-### Non-Blocking but Important
+- **Trigger:** push to `master` (every merged PR)
+- **Purpose:** build, package, and publish a beta pre-release with Docker image
+- **Jobs:**
+    - `version` — compute `vX.Y.Z-beta.<run_number>` from `Cargo.toml`
+    - `build` — 5-target release matrix (linux x86_64/aarch64, macOS x86_64/aarch64, Windows x86_64)
+    - `publish` — create GitHub pre-release with archives + SHA256SUMS
+    - `docker` — build and push multi-platform Docker image to GHCR (`beta` + version tag)
 
-- `.github/workflows/pub-docker-img.yml` (`Docker`)
-    - Purpose: PR Docker smoke check on `dev`/`main` PRs and publish images on tag pushes (`v*`) only
-- `.github/workflows/sec-audit.yml` (`Security Audit`)
-    - Purpose: dependency advisories (`rustsec/audit-check`, pinned SHA) and policy/license checks (`cargo deny`)
-- `.github/workflows/sec-codeql.yml` (`CodeQL Analysis`)
-    - Purpose: scheduled/manual static analysis for security findings
-- `.github/workflows/sec-vorpal-reviewdog.yml` (`Sec Vorpal Reviewdog`)
-    - Purpose: manual secure-coding feedback scan for supported non-Rust files (`.py`, `.js`, `.jsx`, `.ts`, `.tsx`) using reviewdog annotations
-    - Noise control: excludes common test/fixture paths and test file patterns by default (`include_tests=false`)
-- `.github/workflows/pub-release.yml` (`Release`)
-    - Purpose: build release artifacts in verification mode (manual/scheduled) and publish GitHub releases on tag push or manual publish mode
-- `.github/workflows/pub-homebrew-core.yml` (`Pub Homebrew Core`)
-    - Purpose: manual, bot-owned Homebrew core formula bump PR flow for tagged releases
-    - Guardrail: release tag must match `Cargo.toml` version
-- `.github/workflows/pr-label-policy-check.yml` (`Label Policy Sanity`)
-    - Purpose: validate shared contributor-tier policy in `.github/label-policy.json` and ensure label workflows consume that policy
-- `.github/workflows/test-rust-build.yml` (`Rust Reusable Job`)
-    - Purpose: reusable Rust setup/cache + command runner for workflow-call consumers
+### CI Full Matrix (`.github/workflows/ci-full.yml`)
 
-### Optional Repository Automation
+- **Trigger:** manual `workflow_dispatch` only
+- **Purpose:** build release binaries on additional targets not covered by the PR CI
+- **Jobs:**
+    - `build` — 3-target matrix (`aarch64-unknown-linux-gnu`, `x86_64-apple-darwin`, `x86_64-pc-windows-msvc`)
+- **Note:** useful for verifying cross-compilation before a stable release
 
-- `.github/workflows/pr-labeler.yml` (`PR Labeler`)
-    - Purpose: scope/path labels + size/risk labels + fine-grained module labels (`<module>: <component>`)
-    - Additional behavior: label descriptions are auto-managed as hover tooltips to explain each auto-judgment rule
-    - Additional behavior: provider-related keywords in provider/config/onboard/integration changes are promoted to `provider:*` labels (for example `provider:kimi`, `provider:deepseek`)
-    - Additional behavior: hierarchical de-duplication keeps only the most specific scope labels (for example `tool:composio` suppresses `tool:core` and `tool`)
-    - Additional behavior: module namespaces are compacted — one specific module keeps `prefix:component`; multiple specifics collapse to just `prefix`
-    - Additional behavior: applies contributor tiers on PRs by merged PR count (`trusted` >=5, `experienced` >=10, `principal` >=20, `distinguished` >=50)
-    - Additional behavior: final label set is priority-sorted (`risk:*` first, then `size:*`, then contributor tier, then module/path labels)
-    - Additional behavior: managed label colors follow display order to produce a smooth left-to-right gradient when many labels are present
-    - Manual governance: supports `workflow_dispatch` with `mode=audit|repair` to inspect/fix managed label metadata drift across the whole repository
-    - Additional behavior: risk + size labels are auto-corrected on manual PR label edits (`labeled`/`unlabeled` events); apply `risk: manual` when maintainers intentionally override automated risk selection
-    - High-risk heuristic paths: `src/security/**`, `src/runtime/**`, `src/gateway/**`, `src/tools/**`, `.github/workflows/**`
-    - Guardrail: maintainers can apply `risk: manual` to freeze automated risk recalculation
-- `.github/workflows/pr-auto-response.yml` (`PR Auto Responder`)
-    - Purpose: first-time contributor onboarding + label-driven response routing (`r:support`, `r:needs-repro`, etc.)
-    - Additional behavior: applies contributor tiers on issues by merged PR count (`trusted` >=5, `experienced` >=10, `principal` >=20, `distinguished` >=50), matching PR tier thresholds exactly
-    - Additional behavior: contributor-tier labels are treated as automation-managed (manual add/remove on PR/issue is auto-corrected)
-    - Guardrail: label-based close routes are issue-only; PRs are never auto-closed by route labels
-- `.github/workflows/pr-check-stale.yml` (`Stale`)
-    - Purpose: stale issue/PR lifecycle automation
-- `.github/dependabot.yml` (`Dependabot`)
-    - Purpose: grouped, rate-limited dependency update PRs (Cargo + GitHub Actions)
-- `.github/workflows/pr-check-status.yml` (`PR Hygiene`)
-    - Purpose: nudge stale-but-active PRs to rebase/re-run required checks before queue starvation
+### Promote Release (`.github/workflows/promote-release.yml`)
+
+- **Trigger:** manual `workflow_dispatch` with `version` input (e.g. `0.2.0`)
+- **Purpose:** build, package, and publish a stable (non-pre-release) GitHub release with Docker image
+- **Jobs:**
+    - `validate` — confirm input version matches `Cargo.toml`, confirm tag does not already exist
+    - `build` — same 5-target matrix as Beta Release
+    - `publish` — create GitHub stable release with archives + SHA256SUMS
+    - `docker` — build and push multi-platform Docker image to GHCR (`latest` + version tag)
 
 ## Trigger Map
 
-- `CI`: push to `dev` and `main`, PRs to `dev` and `main`
-- `Docker`: tag push (`v*`) for publish, matching PRs to `dev`/`main` for smoke build, manual dispatch for smoke only
-- `Release`: tag push (`v*`), weekly schedule (verification-only), manual dispatch (verification or publish)
-- `Pub Homebrew Core`: manual dispatch only
-- `Security Audit`: push to `dev` and `main`, PRs to `dev` and `main`, weekly schedule
-- `Sec Vorpal Reviewdog`: manual dispatch only
-- `Workflow Sanity`: PR/push when `.github/workflows/**`, `.github/*.yml`, or `.github/*.yaml` change
-- `Main Promotion Gate`: PRs to `main` only; requires PR author `willsarg`/`theonlyhennygod` and head branch `dev` in the same repository
-- `Dependabot`: all update PRs target `dev` (not `main`)
-- `PR Intake Checks`: `pull_request_target` on opened/reopened/synchronize/edited/ready_for_review
-- `Label Policy Sanity`: PR/push when `.github/label-policy.json`, `.github/workflows/pr-labeler.yml`, or `.github/workflows/pr-auto-response.yml` changes
-- `PR Labeler`: `pull_request_target` lifecycle events
-- `PR Auto Responder`: issue opened/labeled, `pull_request_target` opened/labeled
-- `Stale PR Check`: daily schedule, manual dispatch
-- `PR Hygiene`: every 12 hours schedule, manual dispatch
+| Workflow | Trigger |
+|----------|---------|
+| CI | Pull requests to `master` |
+| Beta Release | Push to `master` |
+| CI Full Matrix | Manual dispatch only |
+| Promote Release | Manual dispatch only |
 
 ## Fast Triage Guide
 
-1. `CI Required Gate` failing: start with `.github/workflows/ci-run.yml`.
-2. Docker failures on PRs: inspect `.github/workflows/pub-docker-img.yml` `pr-smoke` job.
-3. Release failures (tag/manual/scheduled): inspect `.github/workflows/pub-release.yml` and the `prepare` job outputs.
-4. Homebrew formula publish failures: inspect `.github/workflows/pub-homebrew-core.yml` summary output and bot token/fork variables.
-5. Security failures: inspect `.github/workflows/sec-audit.yml` and `deny.toml`.
-6. Workflow syntax/lint failures: inspect `.github/workflows/workflow-sanity.yml`.
-7. PR intake failures: inspect `.github/workflows/pr-intake-checks.yml` sticky comment and run logs.
-8. Label policy parity failures: inspect `.github/workflows/pr-label-policy-check.yml`.
-9. Docs failures in CI: inspect `docs-quality` job logs in `.github/workflows/ci-run.yml`.
-10. Strict delta lint failures in CI: inspect `lint-strict-delta` job logs and compare with `BASE_SHA` diff scope.
+1. **CI failing on PR:** inspect `.github/workflows/ci.yml` — check `test` and `build` job logs.
+2. **Beta release failing after merge:** inspect `.github/workflows/release.yml` — check `version`, `build`, `publish`, and `docker` job logs.
+3. **Promote release failing:** inspect `.github/workflows/promote-release.yml` — check `validate` job (version/tag mismatch) and `build`/`publish`/`docker` jobs.
+4. **Cross-platform build issues:** run CI Full Matrix manually via `.github/workflows/ci-full.yml` to test additional targets.
 
 ## Maintenance Rules
 
 - Keep merge-blocking checks deterministic and reproducible (`--locked` where applicable).
-- Follow `docs/release-process.md` for verify-before-publish release cadence and tag discipline.
-- Keep merge-blocking rust quality policy aligned across `.github/workflows/ci-run.yml`, `dev/ci.sh`, and `.githooks/pre-push` (`./scripts/ci/rust_quality_gate.sh` + `./scripts/ci/rust_strict_delta_gate.sh`).
-- Use `./scripts/ci/rust_strict_delta_gate.sh` (or `./dev/ci.sh lint-delta`) as the incremental strict merge gate for changed Rust lines.
-- Run full strict lint audits regularly via `./scripts/ci/rust_quality_gate.sh --strict` (for example through `./dev/ci.sh lint-strict`) and track cleanup in focused PRs.
-- Keep docs markdown gating incremental via `./scripts/ci/docs_quality_gate.sh` (block changed-line issues, report baseline issues separately).
-- Keep docs link gating incremental via `./scripts/ci/collect_changed_links.py` + lychee (check only links added on changed lines).
+- Follow `docs/release-process.md` for release cadence and version discipline.
 - Prefer explicit workflow permissions (least privilege).
 - Keep Actions source policy restricted to approved allowlist patterns (see `docs/actions-source-policy.md`).
-- Use path filters for expensive workflows when practical.
-- Keep docs quality checks low-noise (incremental markdown + incremental added-link checks).
-- Keep dependency update volume controlled (grouping + PR limits).
-- Avoid mixing onboarding/community automation with merge-gating logic.
-
-## Automation Side-Effect Controls
-
-- Prefer deterministic automation that can be manually overridden (`risk: manual`) when context is nuanced.
-- Keep auto-response comments deduplicated to prevent triage noise.
-- Keep auto-close behavior scoped to issues; maintainers own PR close/merge decisions.
-- If automation is wrong, correct labels first, then continue review with explicit rationale.
-- Use `superseded` / `stale-candidate` labels to prune duplicate or dormant PRs before deep review.

docs/i18n/vi/ci-map.md

@@ -2,114 +2,66 @@
 
 Tài liệu này giải thích từng GitHub workflow làm gì, khi nào chạy và liệu nó có nên chặn merge hay không.
 
-Để biết hành vi phân phối theo từng sự kiện qua PR, merge, push và release, xem [`.github/workflows/main-branch-flow.md`](../../../.github/workflows/main-branch-flow.md).
+Để biết hành vi phân phối theo từng sự kiện qua PR, merge, push và release, xem [`.github/workflows/master-branch-flow.md`](../../../.github/workflows/master-branch-flow.md).
 
-## Chặn merge và Tùy chọn
+## Workflows
 
-Các kiểm tra chặn merge nên giữ nhỏ và mang tính quyết định. Các kiểm tra tùy chọn hữu ích cho tự động hóa và bảo trì, nhưng không nên chặn phát triển bình thường.
+### CI (`.github/workflows/ci.yml`)
 
-### Chặn merge
+- **Trigger:** pull request lên `master`
+- **Mục đích:** chạy test và build release binary trên Linux và macOS
+- **Jobs:**
+    - `test` — `cargo nextest run --locked` với mold linker
+    - `build` — ma trận release build (`x86_64-unknown-linux-gnu`, `aarch64-apple-darwin`)
+- **Merge gate:** cả `test` và `build` phải pass trước khi merge
 
-- `.github/workflows/ci-run.yml` (`CI`)
-    - Mục đích: Rust validation (`cargo fmt --all -- --check`, `cargo clippy --locked --all-targets -- -D clippy::correctness`, strict delta lint gate trên các dòng Rust thay đổi, `test`, kiểm tra smoke release build) + kiểm tra chất lượng tài liệu khi tài liệu thay đổi (`markdownlint` chỉ chặn các vấn đề trên dòng thay đổi; link check chỉ quét các link mới được thêm trên dòng thay đổi)
-    - Hành vi bổ sung: các PR thay đổi `.github/workflows/**` yêu cầu ít nhất một review phê duyệt từ login trong `WORKFLOW_OWNER_LOGINS` (fallback biến repository: `theonlyhennygod,willsarg`)
-    - Hành vi bổ sung: lint gate chạy trước `test`/`build`; khi lint/docs gate thất bại trên PR, CI đăng comment phản hồi hành động được với tên gate thất bại và các lệnh sửa cục bộ
-    - Merge gate: `CI Required Gate`
-- `.github/workflows/workflow-sanity.yml` (`Workflow Sanity`)
-    - Mục đích: lint các file GitHub workflow (`actionlint`, kiểm tra tab)
-    - Khuyến nghị cho các PR thay đổi workflow
-- `.github/workflows/pr-intake-checks.yml` (`PR Intake Checks`)
-    - Mục đích: kiểm tra PR an toàn trước CI (độ đầy đủ template, tab/trailing-whitespace/conflict marker trên dòng thêm) với comment sticky phản hồi ngay lập tức
+### Beta Release (`.github/workflows/release.yml`)
 
-### Quan trọng nhưng không chặn
+- **Trigger:** push lên `master` (mỗi PR được merge)
+- **Mục đích:** build, đóng gói và publish beta pre-release với Docker image
+- **Jobs:**
+    - `version` — tính `vX.Y.Z-beta.<run_number>` từ `Cargo.toml`
+    - `build` — ma trận release 5 target (linux x86_64/aarch64, macOS x86_64/aarch64, Windows x86_64)
+    - `publish` — tạo GitHub pre-release với archives + SHA256SUMS
+    - `docker` — build và push Docker image đa nền tảng lên GHCR (`beta` + version tag)
 
-- `.github/workflows/pub-docker-img.yml` (`Docker`)
-    - Mục đích: kiểm tra Docker smoke trên PR và publish image khi push lên `main` (các đường dẫn build-input), push tag (`v*`) và khi dispatch thủ công
-- `.github/workflows/sec-audit.yml` (`Security Audit`)
-    - Mục đích: advisory phụ thuộc (`rustsec/audit-check`, SHA được pin) và kiểm tra chính sách/giấy phép (`cargo deny`)
-- `.github/workflows/sec-codeql.yml` (`CodeQL Analysis`)
-    - Mục đích: phân tích tĩnh theo lịch/thủ công để phát hiện vấn đề bảo mật
-- `.github/workflows/pub-release.yml` (`Release`)
-    - Mục đích: build release artifact ở chế độ xác minh (thủ công/theo lịch) và publish GitHub release khi push tag hoặc chế độ publish thủ công
-- `.github/workflows/pr-label-policy-check.yml` (`Label Policy Sanity`)
-    - Mục đích: xác thực chính sách bậc contributor dùng chung trong `.github/label-policy.json` và đảm bảo các label workflow sử dụng chính sách đó
-- `.github/workflows/test-rust-build.yml` (`Rust Reusable Job`)
-    - Mục đích: Rust setup/cache có thể tái sử dụng + trình chạy lệnh cho các workflow-call consumer
+### CI Full Matrix (`.github/workflows/ci-full.yml`)
 
-### Tự động hóa repository tùy chọn
+- **Trigger:** chỉ `workflow_dispatch` thủ công
+- **Mục đích:** build release binary trên các target bổ sung không có trong PR CI
+- **Jobs:**
+    - `build` — ma trận 3 target (`aarch64-unknown-linux-gnu`, `x86_64-apple-darwin`, `x86_64-pc-windows-msvc`)
+- **Ghi chú:** hữu ích để xác minh cross-compilation trước stable release
 
-- `.github/workflows/pr-labeler.yml` (`PR Labeler`)
-    - Mục đích: nhãn phạm vi/đường dẫn + nhãn kích thước/rủi ro + nhãn module chi tiết (`<module>: <component>`)
-    - Hành vi bổ sung: mô tả nhãn được quản lý tự động như tooltip khi di chuột để giải thích từng quy tắc phán đoán tự động
-    - Hành vi bổ sung: từ khóa liên quan đến provider trong các thay đổi provider/config/onboard/integration được thăng cấp lên nhãn `provider:*` (ví dụ `provider:kimi`, `provider:deepseek`)
-    - Hành vi bổ sung: loại bỏ trùng lặp phân cấp chỉ giữ nhãn phạm vi cụ thể nhất (ví dụ `tool:composio` triệt tiêu `tool:core` và `tool`)
-    - Hành vi bổ sung: namespace module được nén gọn — một module cụ thể giữ `prefix:component`; nhiều module cụ thể thu gọn thành chỉ `prefix`
-    - Hành vi bổ sung: áp dụng bậc contributor trên PR theo số PR đã merge (`trusted` >=5, `experienced` >=10, `principal` >=20, `distinguished` >=50)
-    - Hành vi bổ sung: bộ nhãn cuối cùng được sắp xếp theo ưu tiên (`risk:*` đầu tiên, sau đó `size:*`, rồi bậc contributor, cuối là nhãn module/đường dẫn)
-    - Hành vi bổ sung: màu nhãn được quản lý theo thứ tự hiển thị để tạo gradient trái-phải mượt mà khi có nhiều nhãn
-    - Quản trị thủ công: hỗ trợ `workflow_dispatch` với `mode=audit|repair` để kiểm tra/sửa metadata nhãn được quản lý drift trên toàn repository
-    - Hành vi bổ sung: nhãn rủi ro + kích thước được tự sửa khi chỉnh sửa nhãn PR thủ công (sự kiện `labeled`/`unlabeled`); áp dụng `risk: manual` khi maintainer cố ý ghi đè lựa chọn rủi ro tự động
-    - Đường dẫn heuristic rủi ro cao: `src/security/**`, `src/runtime/**`, `src/gateway/**`, `src/tools/**`, `.github/workflows/**`
-    - Bảo vệ: maintainer có thể áp dụng `risk: manual` để đóng băng tính toán lại rủi ro tự động
-- `.github/workflows/pr-auto-response.yml` (`PR Auto Responder`)
-    - Mục đích: giới thiệu contributor lần đầu + phân tuyến dựa trên nhãn (`r:support`, `r:needs-repro`, v.v.)
-    - Hành vi bổ sung: áp dụng bậc contributor trên issue theo số PR đã merge (`trusted` >=5, `experienced` >=10, `principal` >=20, `distinguished` >=50), khớp chính xác ngưỡng bậc PR
-    - Hành vi bổ sung: nhãn bậc contributor được coi là do tự động hóa quản lý (thêm/xóa thủ công trên PR/issue bị tự sửa)
-    - Bảo vệ: các luồng đóng dựa trên nhãn chỉ dành cho issue; PR không bao giờ bị tự đóng bởi nhãn route
-- `.github/workflows/pr-check-stale.yml` (`Stale`)
-    - Mục đích: tự động hóa vòng đời issue/PR stale
-- `.github/dependabot.yml` (`Dependabot`)
-    - Mục đích: PR cập nhật phụ thuộc được nhóm, giới hạn tốc độ (Cargo + GitHub Actions)
-- `.github/workflows/pr-check-status.yml` (`PR Hygiene`)
-    - Mục đích: nhắc nhở các PR stale-nhưng-còn-hoạt-động để rebase/re-run các kiểm tra bắt buộc trước khi hàng đợi bị đói
+### Promote Release (`.github/workflows/promote-release.yml`)
+
+- **Trigger:** `workflow_dispatch` thủ công với input `version` (ví dụ `0.2.0`)
+- **Mục đích:** build, đóng gói và publish stable release (không phải pre-release) với Docker image
+- **Jobs:**
+    - `validate` — xác nhận version input khớp `Cargo.toml`, xác nhận tag chưa tồn tại
+    - `build` — cùng ma trận 5 target như Beta Release
+    - `publish` — tạo GitHub stable release với archives + SHA256SUMS
+    - `docker` — build và push Docker image đa nền tảng lên GHCR (`latest` + version tag)
 
 ## Bản đồ Trigger
 
-- `CI`: push lên `main`, PR lên `main`
-- `Docker`: push lên `main` khi Docker build input thay đổi, push tag (`v*`), PR tương ứng, dispatch thủ công
-- `Release`: push tag (`v*`), lịch hàng tuần (chỉ xác minh), dispatch thủ công (xác minh hoặc publish)
-- `Security Audit`: push lên `main`, PR lên `main`, lịch hàng tuần
-- `Workflow Sanity`: PR/push khi `.github/workflows/**`, `.github/*.yml` hoặc `.github/*.yaml` thay đổi
-- `PR Intake Checks`: `pull_request_target` khi opened/reopened/synchronize/edited/ready_for_review
-- `Label Policy Sanity`: PR/push khi `.github/label-policy.json`, `.github/workflows/pr-labeler.yml` hoặc `.github/workflows/pr-auto-response.yml` thay đổi
-- `PR Labeler`: sự kiện vòng đời `pull_request_target`
-- `PR Auto Responder`: issue opened/labeled, `pull_request_target` opened/labeled
-- `Stale PR Check`: lịch hàng ngày, dispatch thủ công
-- `Dependabot`: cửa sổ bảo trì phụ thuộc hàng tuần
-- `PR Hygiene`: lịch mỗi 12 giờ, dispatch thủ công
+| Workflow | Trigger |
+|----------|---------|
+| CI | Pull request lên `master` |
+| Beta Release | Push lên `master` |
+| CI Full Matrix | Chỉ dispatch thủ công |
+| Promote Release | Chỉ dispatch thủ công |
 
 ## Hướng dẫn triage nhanh
 
-1. `CI Required Gate` thất bại: bắt đầu với `.github/workflows/ci-run.yml`.
-2. Docker thất bại trên PR: kiểm tra job `pr-smoke` trong `.github/workflows/pub-docker-img.yml`.
-3. Release thất bại (tag/thủ công/theo lịch): kiểm tra `.github/workflows/pub-release.yml` và kết quả job `prepare`.
-4. Security thất bại: kiểm tra `.github/workflows/sec-audit.yml` và `deny.toml`.
-5. Lỗi cú pháp/lint workflow: kiểm tra `.github/workflows/workflow-sanity.yml`.
-6. PR intake thất bại: kiểm tra comment sticky `.github/workflows/pr-intake-checks.yml` và run log.
-7. Lỗi parity chính sách nhãn: kiểm tra `.github/workflows/pr-label-policy-check.yml`.
-8. Lỗi tài liệu trong CI: kiểm tra log job `docs-quality` trong `.github/workflows/ci-run.yml`.
-9. Lỗi strict delta lint trong CI: kiểm tra log job `lint-strict-delta` và so sánh với phạm vi diff `BASE_SHA`.
+1. **CI thất bại trên PR:** kiểm tra `.github/workflows/ci.yml` — xem log job `test` và `build`.
+2. **Beta release thất bại sau merge:** kiểm tra `.github/workflows/release.yml` — xem log job `version`, `build`, `publish` và `docker`.
+3. **Promote release thất bại:** kiểm tra `.github/workflows/promote-release.yml` — xem job `validate` (version/tag không khớp) và các job `build`/`publish`/`docker`.
+4. **Vấn đề build đa nền tảng:** chạy CI Full Matrix thủ công qua `.github/workflows/ci-full.yml` để test các target bổ sung.
 
 ## Quy tắc bảo trì
 
 - Giữ các kiểm tra chặn merge mang tính quyết định và tái tạo được (`--locked` khi áp dụng được).
-- Tuân theo `docs/release-process.md` để kiểm tra trước khi publish và kỷ luật tag.
-- Giữ chính sách chất lượng Rust chặn merge nhất quán giữa `.github/workflows/ci-run.yml`, `dev/ci.sh` và `.githooks/pre-push` (`./scripts/ci/rust_quality_gate.sh` + `./scripts/ci/rust_strict_delta_gate.sh`).
-- Dùng `./scripts/ci/rust_strict_delta_gate.sh` (hoặc `./dev/ci.sh lint-delta`) làm merge gate nghiêm ngặt gia tăng cho các dòng Rust thay đổi.
-- Chạy kiểm tra lint nghiêm ngặt đầy đủ thường xuyên qua `./scripts/ci/rust_quality_gate.sh --strict` (ví dụ qua `./dev/ci.sh lint-strict`) và theo dõi việc dọn dẹp trong các PR tập trung.
-- Giữ gating markdown tài liệu theo gia tăng qua `./scripts/ci/docs_quality_gate.sh` (chặn vấn đề dòng thay đổi, báo cáo vấn đề baseline riêng).
-- Giữ gating link tài liệu theo gia tăng qua `./scripts/ci/collect_changed_links.py` + lychee (chỉ kiểm tra link mới thêm trên dòng thay đổi).
+- Tuân theo `docs/release-process.md` để kiểm tra cadence release và kỷ luật version.
 - Ưu tiên quyền workflow tường minh (least privilege).
 - Giữ chính sách nguồn Actions hạn chế theo allowlist đã được phê duyệt (xem `docs/actions-source-policy.md`).
-- Sử dụng bộ lọc đường dẫn cho các workflow tốn kém khi thực tế.
-- Giữ kiểm tra chất lượng tài liệu ít nhiễu (markdown gia tăng + kiểm tra link mới thêm gia tăng).
-- Giữ khối lượng cập nhật phụ thuộc được kiểm soát (nhóm + giới hạn PR).
-- Tránh kết hợp tự động hóa giới thiệu/cộng đồng với logic gating merge.
-
-## Kiểm soát tác dụng phụ tự động hóa
-
-- Ưu tiên tự động hóa mang tính quyết định có thể ghi đè thủ công (`risk: manual`) khi ngữ cảnh tinh tế.
-- Giữ comment auto-response không trùng lặp để tránh nhiễu triage.
-- Giữ hành vi tự đóng trong phạm vi issue; maintainer quyết định đóng/merge PR.
-- Nếu tự động hóa sai, sửa nhãn trước, rồi tiếp tục review với lý do rõ ràng.
-- Dùng nhãn `superseded` / `stale-candidate` để cắt tỉa PR trùng lặp hoặc ngủ đông trước khi review sâu.

docs/i18n/vi/pr-workflow.md

@@ -37,7 +37,7 @@ Xem tiếp:
 
 - [Mục 5.1](#51-definition-of-ready-dor-trước-khi-yêu-cầu-review)
 
-### 1.2 `CI Required Gate` đang thất bại
+### 1.2 CI check đang thất bại
 
 1. Phân tuyến lỗi qua CI map và ưu tiên sửa các gate mang tính quyết định trước.
 2. Chỉ đánh giá lại rủi ro sau khi CI trả về tín hiệu rõ ràng.
@@ -93,15 +93,14 @@ Tự động hóa hỗ trợ việc triage và bảo vệ, nhưng trách nhiệm
 
 ## 3. Cài đặt repository bắt buộc
 
-Duy trì các quy tắc branch protection sau trên `main`:
+Duy trì các quy tắc branch protection sau trên `master`:
 
-- Yêu cầu status check trước khi merge.
-- Yêu cầu check `CI Required Gate`.
+- Yêu cầu status check trước khi merge (`test` và `build` từ `ci.yml`).
 - Yêu cầu review pull request trước khi merge.
 - Yêu cầu review CODEOWNERS cho các đường dẫn được bảo vệ.
-- Với `.github/workflows/**`, yêu cầu phê duyệt từ owner qua `CI Required Gate` (`WORKFLOW_OWNER_LOGINS`) và giới hạn quyền bypass branch/ruleset cho org owner.
 - Hủy bỏ approval cũ khi có commit mới được đẩy lên.
 - Hạn chế force-push trên các branch được bảo vệ.
+- Tất cả PR contributor hướng trực tiếp đến `master`.
 
 ---
 
@@ -110,19 +109,12 @@ Duy trì các quy tắc branch protection sau trên `main`:
 ### 4.1 Bước A: Intake
 
 - Contributor mở PR với `.github/pull_request_template.md` đầy đủ.
-- `PR Labeler` áp dụng nhãn phạm vi/đường dẫn + nhãn kích thước + nhãn rủi ro + nhãn module (ví dụ `channel:telegram`, `provider:kimi`, `tool:shell`) và bậc contributor theo số PR đã merge (`trusted` >=5, `experienced` >=10, `principal` >=20, `distinguished` >=50), đồng thời loại bỏ trùng lặp nhãn phạm vi ít cụ thể hơn khi đã có nhãn module cụ thể hơn.
-- Đối với tất cả các tiền tố module, nhãn module được nén gọn để giảm nhiễu: một module cụ thể giữ `prefix:component`, nhưng nhiều module cụ thể thu gọn thành nhãn phạm vi cơ sở `prefix`.
-- Thứ tự nhãn ưu tiên đầu tiên: `risk:*` -> `size:*` -> bậc contributor -> nhãn module/đường dẫn.
-- Maintainer có thể chạy `PR Labeler` thủ công (`workflow_dispatch`) ở chế độ `audit` để kiểm tra drift hoặc chế độ `repair` để chuẩn hóa metadata nhãn được quản lý trên toàn repository.
-- Di chuột qua nhãn trên GitHub hiển thị mô tả được quản lý tự động (tóm tắt quy tắc/ngưỡng).
-- Màu nhãn được quản lý được sắp xếp theo thứ tự hiển thị để tạo gradient mượt mà trên các hàng nhãn dài.
-- `PR Auto Responder` đăng hướng dẫn lần đầu, xử lý phân tuyến dựa trên nhãn cho các mục tín hiệu thấp và tự động áp dụng bậc contributor cho issue với cùng ngưỡng như `PR Labeler` (`trusted` >=5, `experienced` >=10, `principal` >=20, `distinguished` >=50).
+- Maintainer áp dụng nhãn phạm vi, kích thước và rủi ro theo nhu cầu.
 
 ### 4.2 Bước B: Validation
 
-- `CI Required Gate` là merge gate.
-- PR chỉ thay đổi tài liệu sử dụng fast-path và bỏ qua các Rust job nặng.
-- PR không phải tài liệu phải vượt qua lint, test và kiểm tra smoke release build.
+- CI check (`test` + `build` từ `ci.yml`) là merge gate.
+- Tất cả PR chạy test suite đầy đủ và kiểm tra release build.
 
 ### 4.3 Bước C: Review
 
@@ -151,7 +143,7 @@ Duy trì các quy tắc branch protection sau trên `main`:
 
 ### 5.2 Definition of Done (DoD) sẵn sàng merge
 
-- `CI Required Gate` đã xanh.
+- CI check đã xanh (`test` + `build`).
 - Các reviewer bắt buộc đã phê duyệt (bao gồm các đường dẫn CODEOWNERS).
 - Nhãn phân loại rủi ro khớp với các đường dẫn đã chạm.
 - Tác động migration/tương thích đã được ghi lại.
@@ -177,8 +169,7 @@ Duy trì các quy tắc branch protection sau trên `main`:
 
 ### 6.3 Hành vi tự động hóa
 
-- `PR Labeler` áp dụng nhãn `size:*` từ số dòng thay đổi thực tế.
-- PR chỉ tài liệu/nặng lockfile được chuẩn hóa để tránh thổi phồng kích thước.
+- Maintainer áp dụng nhãn `size:*` dựa trên số dòng thay đổi thực tế.
 
 ---
 
@@ -213,7 +204,7 @@ Chúng tôi **không** yêu cầu contributor định lượng quyền sở hữ
 - Mục tiêu triage maintainer đầu tiên: trong vòng 48 giờ.
 - Nếu PR bị chặn, maintainer để lại một checklist hành động được.
 - Tự động hóa `stale` được dùng để giữ hàng đợi lành mạnh; maintainer có thể áp dụng `no-stale` khi cần.
-- Tự động hóa `pr-hygiene` kiểm tra các PR mở mỗi 12 giờ và đăng nhắc nhở khi PR không có commit mới trong 48+ giờ và hoặc là đang tụt hậu so với `main` hoặc thiếu/thất bại `CI Required Gate` trên head commit.
+- Maintainer định kỳ kiểm tra các PR cũ cần rebase hoặc chạy lại CI check.
 
 ### 8.1 Kiểm soát ngân sách hàng đợi
 
@@ -229,13 +220,7 @@ Chúng tôi **không** yêu cầu contributor định lượng quyền sở hữ
 
 - `r:needs-repro` cho báo cáo lỗi chưa đầy đủ (yêu cầu repro mang tính quyết định trước khi triage sâu).
 - `r:support` cho các mục sử dụng/trợ giúp nên xử lý ngoài bug backlog.
-- Nhãn `invalid` / `duplicate` kích hoạt tự động hóa đóng **chỉ issue** kèm hướng dẫn.
-
-### 8.4 Bảo vệ tác dụng phụ của tự động hóa
-
-- `PR Auto Responder` loại bỏ trùng lặp comment dựa trên nhãn để tránh spam.
-- Các luồng đóng tự động chỉ giới hạn cho issue, không phải PR.
-- Maintainer có thể đóng băng tính toán lại rủi ro tự động bằng `risk: manual` khi ngữ cảnh yêu cầu ghi đè thủ công.
+- `duplicate` / `invalid` cho các mục không thể hành động.
 
 ---
 
@@ -270,7 +255,7 @@ Các thay đổi ở những khu vực này yêu cầu review chặt chẽ hơn
 
 Nếu một PR đã merge gây ra hồi quy:
 
-1. Revert PR ngay lập tức trên `main`.
+1. Revert PR ngay lập tức trên `master`.
 2. Mở issue theo dõi với phân tích nguyên nhân gốc.
 3. Chỉ đưa lại bản sửa lỗi khi có test hồi quy.
 
@@ -281,8 +266,7 @@ Nếu một PR đã merge gây ra hồi quy:
 ## 11. Checklist merge của maintainer
 
 - Phạm vi tập trung và dễ hiểu.
-- CI gate đã xanh.
-- Kiểm tra chất lượng tài liệu đã xanh khi tài liệu thay đổi.
+- CI check đã xanh (`test` + `build`).
 - Các trường tác động bảo mật đã hoàn thành.
 - Các trường tính riêng tư/vệ sinh dữ liệu đã hoàn thành và bằng chứng đã được biên tập/ẩn danh.
 - Ghi chú workflow agent đủ để tái tạo (nếu tự động hóa được sử dụng).
@@ -298,7 +282,7 @@ Nếu một PR đã merge gây ra hồi quy:
 ### 12.1 Làn A: triage nhanh (thân thiện với agent)
 
 - Xác nhận độ đầy đủ của template PR.
-- Xác nhận tín hiệu CI gate (`CI Required Gate`).
+- Xác nhận CI check pass (`test` + `build`).
 - Xác nhận phân loại rủi ro qua nhãn và các đường dẫn đã chạm.
 - Xác nhận tuyên bố rollback tồn tại.
 - Xác nhận phần tính riêng tư/vệ sinh dữ liệu và các yêu cầu diễn đạt trung lập đã được thỏa mãn.

docs/i18n/vi/release-process.md

@@ -2,111 +2,94 @@
 
 Runbook này định nghĩa quy trình release tiêu chuẩn của maintainer.
 
-Cập nhật lần cuối: **2026-02-20**.
+Cập nhật lần cuối: **2026-03-06**.
 
-## Mục tiêu release
+## Mục tiêu Release
 
-- Đảm bảo release có thể dự đoán và lặp lại.
-- Chỉ publish từ code đã có trên `main`.
-- Xác minh các artifact đa nền tảng trước khi publish.
-- Duy trì nhịp release đều đặn ngay cả khi PR volume cao.
+- Giữ release có thể dự đoán và lặp lại.
+- Chỉ publish từ code đã có trên `master`.
+- Xác minh artifact đa target trước khi publish.
+- Giữ cadence release đều đặn ngay cả khi khối lượng PR cao.
 
-## Chu kỳ tiêu chuẩn
+## Mô hình Release
+
+ZeroClaw sử dụng mô hình release hai tầng:
+
+- **Beta release** tự động — mỗi merge vào `master` kích hoạt beta pre-release (`vX.Y.Z-beta.<run_number>`).
+- **Stable release** thủ công — maintainer chạy `Promote Release` qua workflow dispatch để cắt phiên bản non-pre-release.
+
+## Hợp đồng Workflow
+
+Tự động hóa release nằm trong:
+
+- `.github/workflows/release.yml` — beta release tự động khi push lên `master`
+- `.github/workflows/promote-release.yml` — stable release thủ công qua workflow dispatch
+
+### Beta Release (tự động)
+
+- Kích hoạt trên mỗi push lên `master`.
+- Tính version từ `Cargo.toml`: `vX.Y.Z-beta.<run_number>`.
+- Build ma trận 5 target (linux x86_64/aarch64, macOS x86_64/aarch64, Windows x86_64).
+- Publish GitHub pre-release với archives + SHA256SUMS.
+- Build và push Docker image đa nền tảng lên GHCR (`beta` + version tag).
+
+### Stable Release (thủ công)
+
+- Kích hoạt qua `workflow_dispatch` với input `version` (ví dụ `0.2.0`).
+- Xác thực version khớp `Cargo.toml` và tag chưa tồn tại.
+- Build cùng ma trận 5 target như beta.
+- Publish GitHub stable release với archives + SHA256SUMS.
+- Build và push Docker image lên GHCR (`latest` + version tag).
+
+## Quy trình Maintainer
+
+### 1) Kiểm tra trước trên `master`
+
+1. Đảm bảo CI xanh trên `master` mới nhất.
+2. Xác nhận không có incident ưu tiên cao hoặc regression đã biết đang mở.
+3. Xác nhận các beta release gần đây khỏe mạnh (kiểm tra trang GitHub Releases).
+
+### 2) Tùy chọn: chạy CI Full Matrix
+
+Nếu xác minh cross-compilation trước stable release:
+
+- Chạy `CI Full Matrix` thủ công (`.github/workflows/ci-full.yml`).
+- Xác nhận build thành công trên `aarch64-unknown-linux-gnu`, `x86_64-apple-darwin` và `x86_64-pc-windows-msvc`.
+
+### 3) Tăng version trong `Cargo.toml`
+
+1. Tạo branch, cập nhật `version` trong `Cargo.toml` lên version mục tiêu.
+2. Mở PR, merge vào `master`.
+3. Merge kích hoạt beta release tự động.
+
+### 4) Promote lên stable release
+
+1. Chạy workflow `Promote Release` thủ công:
+   - `version`: version mục tiêu (ví dụ `0.2.0`) — phải khớp `Cargo.toml`
+2. Workflow xác thực version, build tất cả target và publish.
+
+### 5) Xác thực sau release
+
+1. Xác minh asset GitHub Release có thể tải.
+2. Xác minh GHCR tag cho version đã release.
+3. Xác minh đường dẫn cài đặt dựa trên release asset (ví dụ tải binary bootstrap).
+
+## Cadence Tiêu chuẩn
 
 - Release patch/minor: hàng tuần hoặc hai tuần một lần.
-- Bản vá bảo mật khẩn cấp: out-of-band.
-- Không bao giờ chờ tích lũy quá nhiều commit lớn.
+- Sửa bảo mật khẩn cấp: ngoài lịch trình.
+- Beta release ship liên tục với mỗi merge.
 
-## Hợp đồng workflow
+## Đường dẫn Khẩn cấp / Khôi phục
 
-Automation release nằm tại:
+Nếu stable release thất bại:
 
-- `.github/workflows/pub-release.yml`
+1. Sửa vấn đề trên `master`.
+2. Chạy lại `Promote Release` với cùng version (nếu tag chưa được tạo).
+3. Nếu tag đã tồn tại, tăng lên patch version tiếp theo.
 
-Các chế độ:
+## Ghi chú Vận hành
 
-- Tag push `v*`: chế độ publish.
-- Manual dispatch: chế độ chỉ xác minh hoặc publish.
-- Lịch hàng tuần: chế độ chỉ xác minh.
-
-Các guardrail ở chế độ publish:
-
-- Tag phải khớp định dạng semver-like `vX.Y.Z[-suffix]`.
-- Tag phải đã tồn tại trên origin.
-- Commit của tag phải có thể truy vết được từ `origin/main`.
-- GHCR image tag tương ứng (`ghcr.io/<owner>/<repo>:<tag>`) phải sẵn sàng trước khi GitHub Release publish hoàn tất.
-- Artifact được xác minh trước khi publish.
-
-## Quy trình maintainer
-
-### 1) Preflight trên `main`
-
-1. Đảm bảo các required check đều xanh trên `main` mới nhất.
-2. Xác nhận không có sự cố ưu tiên cao hoặc regression đã biết nào đang mở.
-3. Xác nhận các workflow installer và Docker đều khoẻ mạnh trên các commit `main` gần đây.
-
-### 2) Chạy verification build (không publish)
-
-Chạy `Pub Release` thủ công:
-
-- `publish_release`: `false`
-- `release_ref`: `main`
-
-Kết quả mong đợi:
-
-- Ma trận target đầy đủ build thành công.
-- `verify-artifacts` xác nhận tất cả archive mong đợi đều tồn tại.
-- Không có GitHub Release nào được publish.
-
-### 3) Cut release tag
-
-Từ một checkout cục bộ sạch đã sync với `origin/main`:
-
-```bash
-scripts/release/cut_release_tag.sh vX.Y.Z --push
-```
-
-Script này đảm bảo:
-
-- working tree sạch
-- `HEAD == origin/main`
-- tag không bị trùng lặp
-- định dạng tag semver-like
-
-### 4) Theo dõi publish run
-
-Sau khi push tag, theo dõi:
-
-1. Chế độ publish `Pub Release`
-2. Job publish `Pub Docker Img`
-
-Kết quả publish mong đợi:
-
-- release archive
-- `SHA256SUMS`
-- SBOM `CycloneDX` và `SPDX`
-- chữ ký/chứng chỉ cosign
-- GitHub Release notes + asset
-
-### 5) Xác minh sau release
-
-1. Xác minh GitHub Release asset có thể tải xuống.
-2. Xác minh GHCR tag cho phiên bản đã release và `latest`.
-3. Xác minh các đường dẫn cài đặt phụ thuộc vào release asset (ví dụ tải xuống binary bootstrap).
-
-## Đường dẫn khẩn cấp / khôi phục
-
-Nếu release push tag thất bại sau khi artifact đã được xác minh:
-
-1. Sửa vấn đề workflow hoặc packaging trên `main`.
-2. Chạy lại `Pub Release` thủ công ở chế độ publish với:
-   - `publish_release=true`
-   - `release_tag=<existing tag>`
-   - `release_ref` tự động được pin vào `release_tag` ở chế độ publish
-3. Xác minh lại asset đã release.
-
-## Ghi chú vận hành
-
-- Giữ các thay đổi release nhỏ và có thể đảo ngược.
-- Dùng một issue/checklist release cho mỗi phiên bản để bàn giao rõ ràng.
-- Tránh publish từ các feature branch ad-hoc.
+- Giữ thay đổi release nhỏ và có thể đảo ngược.
+- Ưu tiên một issue/checklist release cho mỗi version để handoff rõ ràng.
+- Tránh publish từ các branch tính năng tùy ý.

docs/i18n/vi/reviewer-playbook.md

@@ -81,7 +81,7 @@ Cho mỗi PR mới:
    - nhãn phạm vi (ví dụ `provider`, `channel`, `security`)
    - nhãn có phạm vi module (`channel:*`, `provider:*`, `tool:*`)
    - nhãn bậc contributor khi áp dụng được
-3. Xác nhận trạng thái tín hiệu CI (`CI Required Gate`).
+3. Xác nhận CI check pass (`test` + `build` từ `ci.yml`).
 4. Xác nhận phạm vi là một mối quan tâm (từ chối mega-PR hỗn hợp trừ khi có lý do).
 5. Xác nhận các yêu cầu tính riêng tư/vệ sinh dữ liệu và diễn đạt test trung lập đã được thỏa mãn.
 

docs/pr-workflow.md

@@ -37,7 +37,7 @@ Go to:
 
 - [Section 5.1](#51-definition-of-ready-dor-before-requesting-review)
 
-### 1.2 `CI Required Gate` failing
+### 1.2 CI checks failing
 
 1. Route failure through CI map and fix deterministic gates first.
 2. Re-evaluate risk only after CI returns coherent signal.
@@ -93,18 +93,14 @@ Automation assists with triage and guardrails, but final merge accountability re
 
 ## 3. Required Repository Settings
 
-Maintain these branch protection rules on `dev` and `main`:
+Maintain these branch protection rules on `master`:
 
-- Require status checks before merge.
-- Require check `CI Required Gate`.
+- Require status checks before merge (`test` and `build` from `ci.yml`).
 - Require pull request reviews before merge.
 - Require CODEOWNERS review for protected paths.
-- For `.github/workflows/**`, require owner approval via `CI Required Gate` (`WORKFLOW_OWNER_LOGINS`) and keep branch/ruleset bypass limited to org owners.
-- Default workflow-owner allowlist includes `theonlyhennygod`, `willsarg`, and `chumyin` (plus any comma-separated additions from `WORKFLOW_OWNER_LOGINS`).
 - Dismiss stale approvals when new commits are pushed.
 - Restrict force-push on protected branches.
-- Route normal contributor PRs to `dev`.
-- Allow `main` merges only through a promotion PR from `dev` (enforced by `Main Promotion Gate`).
+- All contributor PRs target `master` directly.
 
 ---
 
@@ -113,20 +109,12 @@ Maintain these branch protection rules on `dev` and `main`:
 ### 4.1 Step A: Intake
 
 - Contributor opens PR with full `.github/pull_request_template.md`.
-- `PR Labeler` applies scope/path labels + size labels + risk labels + module labels (for example `channel:telegram`, `provider:kimi`, `tool:shell`) and contributor tiers by merged PR count (`trusted` >=5, `experienced` >=10, `principal` >=20, `distinguished` >=50), while de-duplicating less-specific scope labels when a more specific module label is present.
-- For all module prefixes, module labels are compacted to reduce noise: one specific module keeps `prefix:component`, but multiple specifics collapse to the base scope label `prefix`.
-- Label ordering is priority-first: `risk:*` -> `size:*` -> contributor tier -> module/path labels.
-- Maintainers can run `PR Labeler` manually (`workflow_dispatch`) in `audit` mode for drift visibility or `repair` mode to normalize managed label metadata repository-wide.
-- Hovering a label in GitHub shows its auto-managed description (rule/threshold summary).
-- Managed label colors are arranged by display order to create a smooth gradient across long label rows.
-- `PR Auto Responder` posts first-time guidance, handles label-driven routing for low-signal items, and auto-applies issue contributor tiers using the same thresholds as `PR Labeler` (`trusted` >=5, `experienced` >=10, `principal` >=20, `distinguished` >=50).
+- Maintainers manually apply scope, size, and risk labels as needed.
 
 ### 4.2 Step B: Validation
 
-- `CI Required Gate` is the merge gate.
-- Docs-only PRs use fast-path and skip heavy Rust jobs.
-- Non-doc PRs must pass lint, tests, and release build smoke check.
-- Rust-impacting PRs use the same required gate set as `dev`/`main` pushes (no PR build-only shortcut).
+- CI checks (`test` + `build` from `ci.yml`) are the merge gate.
+- All PRs run the full test suite and release build check.
 
 ### 4.3 Step C: Review
 
@@ -155,7 +143,7 @@ Maintain these branch protection rules on `dev` and `main`:
 
 ### 5.2 Definition of Done (DoD) merge-ready
 
-- `CI Required Gate` is green.
+- CI checks are green (`test` + `build`).
 - Required reviewers approved (including CODEOWNERS paths).
 - Risk class labels match touched paths.
 - Migration/compatibility impact is documented.
@@ -217,7 +205,7 @@ We do **not** require contributors to quantify AI-vs-human line ownership.
 - First maintainer triage target: within 48 hours.
 - If PR is blocked, maintainer leaves one actionable checklist.
 - `stale` automation is used to keep queue healthy; maintainers can apply `no-stale` when needed.
-- `pr-hygiene` automation checks open PRs every 12 hours and posts a nudge when a PR has no new commits for 48+ hours and is either behind `main` or missing/failing `CI Required Gate` on the head commit.
+- Maintainers periodically check for stale PRs that need rebase or re-run of CI checks.
 
 ### 8.1 Queue budget controls
 
@@ -233,13 +221,7 @@ We do **not** require contributors to quantify AI-vs-human line ownership.
 
 - `r:needs-repro` for incomplete bug reports (request deterministic repro before deep triage).
 - `r:support` for usage/help items better handled outside bug backlog.
-- `invalid` / `duplicate` labels trigger **issue-only** closing automation with guidance.
-
-### 8.4 Automation side-effect guards
-
-- `PR Auto Responder` deduplicates label-based comments to avoid spam.
-- Automated close routes are limited to issues, not PRs.
-- Maintainers can freeze automated risk recalculation with `risk: manual` when context demands human override.
+- `duplicate` / `invalid` for non-actionable items.
 
 ---
 
@@ -274,7 +256,7 @@ For agent-assisted contributions, reviewers should also verify the author demons
 
 If a merged PR causes regressions:
 
-1. Revert PR immediately on `main`.
+1. Revert PR immediately on `master`.
 2. Open a follow-up issue with root-cause analysis.
 3. Re-introduce fix only with regression tests.
 
@@ -285,8 +267,7 @@ Prefer fast restore of service quality over delayed perfect fixes.
 ## 11. Maintainer Merge Checklist
 
 - Scope is focused and understandable.
-- CI gate is green.
-- Docs-quality checks are green when docs changed.
+- CI checks are green (`test` + `build`).
 - Security impact fields are complete.
 - Privacy/data-hygiene fields are complete and evidence is redacted/anonymized.
 - Agent workflow notes are sufficient for reproducibility (if automation was used).
@@ -302,7 +283,7 @@ To keep review quality stable under high PR volume, use a two-lane review model.
 ### 12.1 Lane A: fast triage (agent-friendly)
 
 - Confirm PR template completeness.
-- Confirm CI gate signal (`CI Required Gate`).
+- Confirm CI checks pass (`test` + `build`).
 - Confirm risk class via labels and touched paths.
 - Confirm rollback statement exists.
 - Confirm privacy/data-hygiene section and neutral wording requirements are satisfied.

docs/release-process.md

@@ -2,129 +2,91 @@
 
 This runbook defines the maintainers' standard release flow.
 
-Last verified: **February 21, 2026**.
+Last verified: **March 6, 2026**.
 
 ## Release Goals
 
 - Keep releases predictable and repeatable.
-- Publish only from code already in `main`.
+- Publish only from code already in `master`.
 - Verify multi-target artifacts before publish.
 - Keep release cadence regular even with high PR volume.
 
-## Standard Cadence
+## Release Model
 
-- Patch/minor releases: weekly or bi-weekly.
-- Emergency security fixes: out-of-band.
-- Never wait for very large commit batches to accumulate.
+ZeroClaw uses a two-tier release model:
+
+- **Beta releases** are automatic — every merge to `master` triggers a beta pre-release (`vX.Y.Z-beta.<run_number>`).
+- **Stable releases** are manual — a maintainer runs `Promote Release` via workflow dispatch to cut a non-pre-release version.
 
 ## Workflow Contract
 
 Release automation lives in:
 
-- `.github/workflows/pub-release.yml`
-- `.github/workflows/pub-homebrew-core.yml` (manual Homebrew formula PR, bot-owned)
+- `.github/workflows/release.yml` — automatic beta release on push to `master`
+- `.github/workflows/promote-release.yml` — manual stable release via workflow dispatch
 
-Modes:
+### Beta Release (automatic)
 
-- Tag push `v*`: publish mode.
-- Manual dispatch: verification-only or publish mode.
-- Weekly schedule: verification-only mode.
+- Triggered on every push to `master`.
+- Computes version from `Cargo.toml`: `vX.Y.Z-beta.<run_number>`.
+- Builds 5-target matrix (linux x86_64/aarch64, macOS x86_64/aarch64, Windows x86_64).
+- Publishes GitHub pre-release with archives + SHA256SUMS.
+- Builds and pushes multi-platform Docker image to GHCR (`beta` + version tag).
 
-Publish-mode guardrails:
+### Stable Release (manual)
 
-- Tag must match semver-like format `vX.Y.Z[-suffix]`.
-- Tag must already exist on origin.
-- Tag commit must be reachable from `origin/main`.
-- Matching GHCR image tag (`ghcr.io/<owner>/<repo>:<tag>`) must be available before GitHub Release publish completes.
-- Artifacts are verified before publish.
+- Triggered via `workflow_dispatch` with a `version` input (e.g. `0.2.0`).
+- Validates version matches `Cargo.toml` and tag does not already exist.
+- Builds same 5-target matrix as beta.
+- Publishes GitHub stable release with archives + SHA256SUMS.
+- Builds and pushes Docker image to GHCR (`latest` + version tag).
 
 ## Maintainer Procedure
 
-### 1) Preflight on `main`
+### 1) Preflight on `master`
 
-1. Ensure required checks are green on latest `main`.
+1. Ensure CI is green on latest `master`.
 2. Confirm no high-priority incidents or known regressions are open.
-3. Confirm installer and Docker workflows are healthy on recent `main` commits.
+3. Confirm recent beta releases are healthy (check GitHub Releases page).
 
-### 2) Run verification build (no publish)
+### 2) Optional: run CI Full Matrix
 
-Run `Pub Release` manually:
+If verifying cross-compilation before a stable release:
 
-- `publish_release`: `false`
-- `release_ref`: `main`
+- Run `CI Full Matrix` manually (`.github/workflows/ci-full.yml`).
+- Confirms builds succeed on `aarch64-unknown-linux-gnu`, `x86_64-apple-darwin`, and `x86_64-pc-windows-msvc`.
 
-Expected outcome:
+### 3) Bump version in `Cargo.toml`
 
-- Full target matrix builds successfully.
-- `verify-artifacts` confirms all expected archives exist.
-- No GitHub Release is published.
+1. Create a branch, update `version` in `Cargo.toml` to the target version.
+2. Open PR, merge to `master`.
+3. The merge triggers a beta release automatically.
 
-### 3) Cut release tag
+### 4) Promote to stable release
 
-From a clean local checkout synced to `origin/main`:
-
-```bash
-scripts/release/cut_release_tag.sh vX.Y.Z --push
-```
-
-This script enforces:
-
-- clean working tree
-- `HEAD == origin/main`
-- non-duplicate tag
-- semver-like tag format
-
-### 4) Monitor publish run
-
-After tag push, monitor:
-
-1. `Pub Release` publish mode
-2. `Pub Docker Img` publish job
-
-Expected publish outputs:
-
-- release archives
-- `SHA256SUMS`
-- `CycloneDX` and `SPDX` SBOMs
-- cosign signatures/certificates
-- GitHub Release notes + assets
+1. Run `Promote Release` workflow manually:
+   - `version`: the target version (e.g. `0.2.0`) — must match `Cargo.toml`
+2. Workflow validates version, builds all targets, and publishes.
 
 ### 5) Post-release validation
 
 1. Verify GitHub Release assets are downloadable.
-2. Verify GHCR tags for the released version (`vX.Y.Z`) and release commit SHA tag (`sha-<12>`).
+2. Verify GHCR tags for the released version.
 3. Verify install paths that rely on release assets (for example bootstrap binary download).
 
-### 6) Publish Homebrew Core formula (bot-owned)
+## Standard Cadence
 
-Run `Pub Homebrew Core` manually:
-
-- `release_tag`: `vX.Y.Z`
-- `dry_run`: `true` first, then `false`
-
-Required repository settings for non-dry-run:
-
-- secret: `HOMEBREW_CORE_BOT_TOKEN` (token from a dedicated bot account, not a personal maintainer account)
-- variable: `HOMEBREW_CORE_BOT_FORK_REPO` (for example `zeroclaw-release-bot/homebrew-core`)
-- optional variable: `HOMEBREW_CORE_BOT_EMAIL`
-
-Workflow guardrails:
-
-- release tag must match `Cargo.toml` version
-- formula source URL and SHA256 are updated from the tagged tarball
-- formula license is normalized to `Apache-2.0 OR MIT`
-- PR is opened from the bot fork into `Homebrew/homebrew-core:master`
+- Patch/minor releases: weekly or bi-weekly.
+- Emergency security fixes: out-of-band.
+- Beta releases ship continuously with every merge.
 
 ## Emergency / Recovery Path
 
-If tag-push release fails after artifacts are validated:
+If a stable release fails:
 
-1. Fix workflow or packaging issue on `main`.
-2. Re-run manual `Pub Release` in publish mode with:
-   - `publish_release=true`
-   - `release_tag=<existing tag>`
-   - `release_ref` is automatically pinned to `release_tag` in publish mode
-3. Re-validate released assets.
+1. Fix the issue on `master`.
+2. Re-run `Promote Release` with the same version (if the tag was not yet created).
+3. If the tag already exists, bump to the next patch version.
 
 ## Operational Notes
 

docs/reviewer-playbook.md

@@ -81,7 +81,7 @@ For every new PR:
    - scope labels (for example `provider`, `channel`, `security`)
    - module-scoped labels (`channel:*`, `provider:*`, `tool:*`)
    - contributor tier labels when applicable
-3. Confirm CI signal status (`CI Required Gate`).
+3. Confirm CI checks pass (`test` + `build` from `ci.yml`).
 4. Confirm scope is one concern (reject mixed mega-PRs unless justified).
 5. Confirm privacy/data-hygiene and neutral test wording requirements are satisfied.
 

docs/vi/ci-map.md

@@ -2,114 +2,66 @@
 
 Tài liệu này giải thích từng GitHub workflow làm gì, khi nào chạy và liệu nó có nên chặn merge hay không.
 
-Để biết hành vi phân phối theo từng sự kiện qua PR, merge, push và release, xem [`.github/workflows/main-branch-flow.md`](../../.github/workflows/main-branch-flow.md).
+Để biết hành vi phân phối theo từng sự kiện qua PR, merge, push và release, xem [`.github/workflows/master-branch-flow.md`](../../.github/workflows/master-branch-flow.md).
 
-## Chặn merge và Tùy chọn
+## Workflows
 
-Các kiểm tra chặn merge nên giữ nhỏ và mang tính quyết định. Các kiểm tra tùy chọn hữu ích cho tự động hóa và bảo trì, nhưng không nên chặn phát triển bình thường.
+### CI (`.github/workflows/ci.yml`)
 
-### Chặn merge
+- **Trigger:** pull request lên `master`
+- **Mục đích:** chạy test và build release binary trên Linux và macOS
+- **Jobs:**
+    - `test` — `cargo nextest run --locked` với mold linker
+    - `build` — ma trận release build (`x86_64-unknown-linux-gnu`, `aarch64-apple-darwin`)
+- **Merge gate:** cả `test` và `build` phải pass trước khi merge
 
-- `.github/workflows/ci-run.yml` (`CI`)
-    - Mục đích: Rust validation (`cargo fmt --all -- --check`, `cargo clippy --locked --all-targets -- -D clippy::correctness`, strict delta lint gate trên các dòng Rust thay đổi, `test`, kiểm tra smoke release build) + kiểm tra chất lượng tài liệu khi tài liệu thay đổi (`markdownlint` chỉ chặn các vấn đề trên dòng thay đổi; link check chỉ quét các link mới được thêm trên dòng thay đổi)
-    - Hành vi bổ sung: các PR thay đổi `.github/workflows/**` yêu cầu ít nhất một review phê duyệt từ login trong `WORKFLOW_OWNER_LOGINS` (fallback biến repository: `theonlyhennygod,willsarg`)
-    - Hành vi bổ sung: lint gate chạy trước `test`/`build`; khi lint/docs gate thất bại trên PR, CI đăng comment phản hồi hành động được với tên gate thất bại và các lệnh sửa cục bộ
-    - Merge gate: `CI Required Gate`
-- `.github/workflows/workflow-sanity.yml` (`Workflow Sanity`)
-    - Mục đích: lint các file GitHub workflow (`actionlint`, kiểm tra tab)
-    - Khuyến nghị cho các PR thay đổi workflow
-- `.github/workflows/pr-intake-checks.yml` (`PR Intake Checks`)
-    - Mục đích: kiểm tra PR an toàn trước CI (độ đầy đủ template, tab/trailing-whitespace/conflict marker trên dòng thêm) với comment sticky phản hồi ngay lập tức
+### Beta Release (`.github/workflows/release.yml`)
 
-### Quan trọng nhưng không chặn
+- **Trigger:** push lên `master` (mỗi PR được merge)
+- **Mục đích:** build, đóng gói và publish beta pre-release với Docker image
+- **Jobs:**
+    - `version` — tính `vX.Y.Z-beta.<run_number>` từ `Cargo.toml`
+    - `build` — ma trận release 5 target (linux x86_64/aarch64, macOS x86_64/aarch64, Windows x86_64)
+    - `publish` — tạo GitHub pre-release với archives + SHA256SUMS
+    - `docker` — build và push Docker image đa nền tảng lên GHCR (`beta` + version tag)
 
-- `.github/workflows/pub-docker-img.yml` (`Docker`)
-    - Mục đích: kiểm tra Docker smoke trên PR và publish image khi push lên `main` (các đường dẫn build-input), push tag (`v*`) và khi dispatch thủ công
-- `.github/workflows/sec-audit.yml` (`Security Audit`)
-    - Mục đích: advisory phụ thuộc (`rustsec/audit-check`, SHA được pin) và kiểm tra chính sách/giấy phép (`cargo deny`)
-- `.github/workflows/sec-codeql.yml` (`CodeQL Analysis`)
-    - Mục đích: phân tích tĩnh theo lịch/thủ công để phát hiện vấn đề bảo mật
-- `.github/workflows/pub-release.yml` (`Release`)
-    - Mục đích: build release artifact ở chế độ xác minh (thủ công/theo lịch) và publish GitHub release khi push tag hoặc chế độ publish thủ công
-- `.github/workflows/pr-label-policy-check.yml` (`Label Policy Sanity`)
-    - Mục đích: xác thực chính sách bậc contributor dùng chung trong `.github/label-policy.json` và đảm bảo các label workflow sử dụng chính sách đó
-- `.github/workflows/test-rust-build.yml` (`Rust Reusable Job`)
-    - Mục đích: Rust setup/cache có thể tái sử dụng + trình chạy lệnh cho các workflow-call consumer
+### CI Full Matrix (`.github/workflows/ci-full.yml`)
 
-### Tự động hóa repository tùy chọn
+- **Trigger:** chỉ `workflow_dispatch` thủ công
+- **Mục đích:** build release binary trên các target bổ sung không có trong PR CI
+- **Jobs:**
+    - `build` — ma trận 3 target (`aarch64-unknown-linux-gnu`, `x86_64-apple-darwin`, `x86_64-pc-windows-msvc`)
+- **Ghi chú:** hữu ích để xác minh cross-compilation trước stable release
 
-- `.github/workflows/pr-labeler.yml` (`PR Labeler`)
-    - Mục đích: nhãn phạm vi/đường dẫn + nhãn kích thước/rủi ro + nhãn module chi tiết (`<module>: <component>`)
-    - Hành vi bổ sung: mô tả nhãn được quản lý tự động như tooltip khi di chuột để giải thích từng quy tắc phán đoán tự động
-    - Hành vi bổ sung: từ khóa liên quan đến provider trong các thay đổi provider/config/onboard/integration được thăng cấp lên nhãn `provider:*` (ví dụ `provider:kimi`, `provider:deepseek`)
-    - Hành vi bổ sung: loại bỏ trùng lặp phân cấp chỉ giữ nhãn phạm vi cụ thể nhất (ví dụ `tool:composio` triệt tiêu `tool:core` và `tool`)
-    - Hành vi bổ sung: namespace module được nén gọn — một module cụ thể giữ `prefix:component`; nhiều module cụ thể thu gọn thành chỉ `prefix`
-    - Hành vi bổ sung: áp dụng bậc contributor trên PR theo số PR đã merge (`trusted` >=5, `experienced` >=10, `principal` >=20, `distinguished` >=50)
-    - Hành vi bổ sung: bộ nhãn cuối cùng được sắp xếp theo ưu tiên (`risk:*` đầu tiên, sau đó `size:*`, rồi bậc contributor, cuối là nhãn module/đường dẫn)
-    - Hành vi bổ sung: màu nhãn được quản lý theo thứ tự hiển thị để tạo gradient trái-phải mượt mà khi có nhiều nhãn
-    - Quản trị thủ công: hỗ trợ `workflow_dispatch` với `mode=audit|repair` để kiểm tra/sửa metadata nhãn được quản lý drift trên toàn repository
-    - Hành vi bổ sung: nhãn rủi ro + kích thước được tự sửa khi chỉnh sửa nhãn PR thủ công (sự kiện `labeled`/`unlabeled`); áp dụng `risk: manual` khi maintainer cố ý ghi đè lựa chọn rủi ro tự động
-    - Đường dẫn heuristic rủi ro cao: `src/security/**`, `src/runtime/**`, `src/gateway/**`, `src/tools/**`, `.github/workflows/**`
-    - Bảo vệ: maintainer có thể áp dụng `risk: manual` để đóng băng tính toán lại rủi ro tự động
-- `.github/workflows/pr-auto-response.yml` (`PR Auto Responder`)
-    - Mục đích: giới thiệu contributor lần đầu + phân tuyến dựa trên nhãn (`r:support`, `r:needs-repro`, v.v.)
-    - Hành vi bổ sung: áp dụng bậc contributor trên issue theo số PR đã merge (`trusted` >=5, `experienced` >=10, `principal` >=20, `distinguished` >=50), khớp chính xác ngưỡng bậc PR
-    - Hành vi bổ sung: nhãn bậc contributor được coi là do tự động hóa quản lý (thêm/xóa thủ công trên PR/issue bị tự sửa)
-    - Bảo vệ: các luồng đóng dựa trên nhãn chỉ dành cho issue; PR không bao giờ bị tự đóng bởi nhãn route
-- `.github/workflows/pr-check-stale.yml` (`Stale`)
-    - Mục đích: tự động hóa vòng đời issue/PR stale
-- `.github/dependabot.yml` (`Dependabot`)
-    - Mục đích: PR cập nhật phụ thuộc được nhóm, giới hạn tốc độ (Cargo + GitHub Actions)
-- `.github/workflows/pr-check-status.yml` (`PR Hygiene`)
-    - Mục đích: nhắc nhở các PR stale-nhưng-còn-hoạt-động để rebase/re-run các kiểm tra bắt buộc trước khi hàng đợi bị đói
+### Promote Release (`.github/workflows/promote-release.yml`)
+
+- **Trigger:** `workflow_dispatch` thủ công với input `version` (ví dụ `0.2.0`)
+- **Mục đích:** build, đóng gói và publish stable release (không phải pre-release) với Docker image
+- **Jobs:**
+    - `validate` — xác nhận version input khớp `Cargo.toml`, xác nhận tag chưa tồn tại
+    - `build` — cùng ma trận 5 target như Beta Release
+    - `publish` — tạo GitHub stable release với archives + SHA256SUMS
+    - `docker` — build và push Docker image đa nền tảng lên GHCR (`latest` + version tag)
 
 ## Bản đồ Trigger
 
-- `CI`: push lên `main`, PR lên `main`
-- `Docker`: push lên `main` khi Docker build input thay đổi, push tag (`v*`), PR tương ứng, dispatch thủ công
-- `Release`: push tag (`v*`), lịch hàng tuần (chỉ xác minh), dispatch thủ công (xác minh hoặc publish)
-- `Security Audit`: push lên `main`, PR lên `main`, lịch hàng tuần
-- `Workflow Sanity`: PR/push khi `.github/workflows/**`, `.github/*.yml` hoặc `.github/*.yaml` thay đổi
-- `PR Intake Checks`: `pull_request_target` khi opened/reopened/synchronize/edited/ready_for_review
-- `Label Policy Sanity`: PR/push khi `.github/label-policy.json`, `.github/workflows/pr-labeler.yml` hoặc `.github/workflows/pr-auto-response.yml` thay đổi
-- `PR Labeler`: sự kiện vòng đời `pull_request_target`
-- `PR Auto Responder`: issue opened/labeled, `pull_request_target` opened/labeled
-- `Stale PR Check`: lịch hàng ngày, dispatch thủ công
-- `Dependabot`: cửa sổ bảo trì phụ thuộc hàng tuần
-- `PR Hygiene`: lịch mỗi 12 giờ, dispatch thủ công
+| Workflow | Trigger |
+|----------|---------|
+| CI | Pull request lên `master` |
+| Beta Release | Push lên `master` |
+| CI Full Matrix | Chỉ dispatch thủ công |
+| Promote Release | Chỉ dispatch thủ công |
 
 ## Hướng dẫn triage nhanh
 
-1. `CI Required Gate` thất bại: bắt đầu với `.github/workflows/ci-run.yml`.
-2. Docker thất bại trên PR: kiểm tra job `pr-smoke` trong `.github/workflows/pub-docker-img.yml`.
-3. Release thất bại (tag/thủ công/theo lịch): kiểm tra `.github/workflows/pub-release.yml` và kết quả job `prepare`.
-4. Security thất bại: kiểm tra `.github/workflows/sec-audit.yml` và `deny.toml`.
-5. Lỗi cú pháp/lint workflow: kiểm tra `.github/workflows/workflow-sanity.yml`.
-6. PR intake thất bại: kiểm tra comment sticky `.github/workflows/pr-intake-checks.yml` và run log.
-7. Lỗi parity chính sách nhãn: kiểm tra `.github/workflows/pr-label-policy-check.yml`.
-8. Lỗi tài liệu trong CI: kiểm tra log job `docs-quality` trong `.github/workflows/ci-run.yml`.
-9. Lỗi strict delta lint trong CI: kiểm tra log job `lint-strict-delta` và so sánh với phạm vi diff `BASE_SHA`.
+1. **CI thất bại trên PR:** kiểm tra `.github/workflows/ci.yml` — xem log job `test` và `build`.
+2. **Beta release thất bại sau merge:** kiểm tra `.github/workflows/release.yml` — xem log job `version`, `build`, `publish` và `docker`.
+3. **Promote release thất bại:** kiểm tra `.github/workflows/promote-release.yml` — xem job `validate` (version/tag không khớp) và các job `build`/`publish`/`docker`.
+4. **Vấn đề build đa nền tảng:** chạy CI Full Matrix thủ công qua `.github/workflows/ci-full.yml` để test các target bổ sung.
 
 ## Quy tắc bảo trì
 
 - Giữ các kiểm tra chặn merge mang tính quyết định và tái tạo được (`--locked` khi áp dụng được).
-- Tuân theo `docs/release-process.md` để kiểm tra trước khi publish và kỷ luật tag.
-- Giữ chính sách chất lượng Rust chặn merge nhất quán giữa `.github/workflows/ci-run.yml`, `dev/ci.sh` và `.githooks/pre-push` (`./scripts/ci/rust_quality_gate.sh` + `./scripts/ci/rust_strict_delta_gate.sh`).
-- Dùng `./scripts/ci/rust_strict_delta_gate.sh` (hoặc `./dev/ci.sh lint-delta`) làm merge gate nghiêm ngặt gia tăng cho các dòng Rust thay đổi.
-- Chạy kiểm tra lint nghiêm ngặt đầy đủ thường xuyên qua `./scripts/ci/rust_quality_gate.sh --strict` (ví dụ qua `./dev/ci.sh lint-strict`) và theo dõi việc dọn dẹp trong các PR tập trung.
-- Giữ gating markdown tài liệu theo gia tăng qua `./scripts/ci/docs_quality_gate.sh` (chặn vấn đề dòng thay đổi, báo cáo vấn đề baseline riêng).
-- Giữ gating link tài liệu theo gia tăng qua `./scripts/ci/collect_changed_links.py` + lychee (chỉ kiểm tra link mới thêm trên dòng thay đổi).
+- Tuân theo `docs/release-process.md` để kiểm tra cadence release và kỷ luật version.
 - Ưu tiên quyền workflow tường minh (least privilege).
 - Giữ chính sách nguồn Actions hạn chế theo allowlist đã được phê duyệt (xem `docs/actions-source-policy.md`).
-- Sử dụng bộ lọc đường dẫn cho các workflow tốn kém khi thực tế.
-- Giữ kiểm tra chất lượng tài liệu ít nhiễu (markdown gia tăng + kiểm tra link mới thêm gia tăng).
-- Giữ khối lượng cập nhật phụ thuộc được kiểm soát (nhóm + giới hạn PR).
-- Tránh kết hợp tự động hóa giới thiệu/cộng đồng với logic gating merge.
-
-## Kiểm soát tác dụng phụ tự động hóa
-
-- Ưu tiên tự động hóa mang tính quyết định có thể ghi đè thủ công (`risk: manual`) khi ngữ cảnh tinh tế.
-- Giữ comment auto-response không trùng lặp để tránh nhiễu triage.
-- Giữ hành vi tự đóng trong phạm vi issue; maintainer quyết định đóng/merge PR.
-- Nếu tự động hóa sai, sửa nhãn trước, rồi tiếp tục review với lý do rõ ràng.
-- Dùng nhãn `superseded` / `stale-candidate` để cắt tỉa PR trùng lặp hoặc ngủ đông trước khi review sâu.

docs/vi/pr-workflow.md

@@ -37,7 +37,7 @@ Xem tiếp:
 
 - [Mục 5.1](#51-definition-of-ready-dor-trước-khi-yêu-cầu-review)
 
-### 1.2 `CI Required Gate` đang thất bại
+### 1.2 CI check đang thất bại
 
 1. Phân tuyến lỗi qua CI map và ưu tiên sửa các gate mang tính quyết định trước.
 2. Chỉ đánh giá lại rủi ro sau khi CI trả về tín hiệu rõ ràng.
@@ -93,15 +93,14 @@ Tự động hóa hỗ trợ việc triage và bảo vệ, nhưng trách nhiệm
 
 ## 3. Cài đặt repository bắt buộc
 
-Duy trì các quy tắc branch protection sau trên `main`:
+Duy trì các quy tắc branch protection sau trên `master`:
 
-- Yêu cầu status check trước khi merge.
-- Yêu cầu check `CI Required Gate`.
+- Yêu cầu status check trước khi merge (`test` và `build` từ `ci.yml`).
 - Yêu cầu review pull request trước khi merge.
 - Yêu cầu review CODEOWNERS cho các đường dẫn được bảo vệ.
-- Với `.github/workflows/**`, yêu cầu phê duyệt từ owner qua `CI Required Gate` (`WORKFLOW_OWNER_LOGINS`) và giới hạn quyền bypass branch/ruleset cho org owner.
 - Hủy bỏ approval cũ khi có commit mới được đẩy lên.
 - Hạn chế force-push trên các branch được bảo vệ.
+- Tất cả PR contributor hướng trực tiếp đến `master`.
 
 ---
 
@@ -110,19 +109,12 @@ Duy trì các quy tắc branch protection sau trên `main`:
 ### 4.1 Bước A: Intake
 
 - Contributor mở PR với `.github/pull_request_template.md` đầy đủ.
-- `PR Labeler` áp dụng nhãn phạm vi/đường dẫn + nhãn kích thước + nhãn rủi ro + nhãn module (ví dụ `channel:telegram`, `provider:kimi`, `tool:shell`) và bậc contributor theo số PR đã merge (`trusted` >=5, `experienced` >=10, `principal` >=20, `distinguished` >=50), đồng thời loại bỏ trùng lặp nhãn phạm vi ít cụ thể hơn khi đã có nhãn module cụ thể hơn.
-- Đối với tất cả các tiền tố module, nhãn module được nén gọn để giảm nhiễu: một module cụ thể giữ `prefix:component`, nhưng nhiều module cụ thể thu gọn thành nhãn phạm vi cơ sở `prefix`.
-- Thứ tự nhãn ưu tiên đầu tiên: `risk:*` -> `size:*` -> bậc contributor -> nhãn module/đường dẫn.
-- Maintainer có thể chạy `PR Labeler` thủ công (`workflow_dispatch`) ở chế độ `audit` để kiểm tra drift hoặc chế độ `repair` để chuẩn hóa metadata nhãn được quản lý trên toàn repository.
-- Di chuột qua nhãn trên GitHub hiển thị mô tả được quản lý tự động (tóm tắt quy tắc/ngưỡng).
-- Màu nhãn được quản lý được sắp xếp theo thứ tự hiển thị để tạo gradient mượt mà trên các hàng nhãn dài.
-- `PR Auto Responder` đăng hướng dẫn lần đầu, xử lý phân tuyến dựa trên nhãn cho các mục tín hiệu thấp và tự động áp dụng bậc contributor cho issue với cùng ngưỡng như `PR Labeler` (`trusted` >=5, `experienced` >=10, `principal` >=20, `distinguished` >=50).
+- Maintainer áp dụng nhãn phạm vi, kích thước và rủi ro theo nhu cầu.
 
 ### 4.2 Bước B: Validation
 
-- `CI Required Gate` là merge gate.
-- PR chỉ thay đổi tài liệu sử dụng fast-path và bỏ qua các Rust job nặng.
-- PR không phải tài liệu phải vượt qua lint, test và kiểm tra smoke release build.
+- CI check (`test` + `build` từ `ci.yml`) là merge gate.
+- Tất cả PR chạy test suite đầy đủ và kiểm tra release build.
 
 ### 4.3 Bước C: Review
 
@@ -151,7 +143,7 @@ Duy trì các quy tắc branch protection sau trên `main`:
 
 ### 5.2 Definition of Done (DoD) sẵn sàng merge
 
-- `CI Required Gate` đã xanh.
+- CI check đã xanh (`test` + `build`).
 - Các reviewer bắt buộc đã phê duyệt (bao gồm các đường dẫn CODEOWNERS).
 - Nhãn phân loại rủi ro khớp với các đường dẫn đã chạm.
 - Tác động migration/tương thích đã được ghi lại.
@@ -177,8 +169,7 @@ Duy trì các quy tắc branch protection sau trên `main`:
 
 ### 6.3 Hành vi tự động hóa
 
-- `PR Labeler` áp dụng nhãn `size:*` từ số dòng thay đổi thực tế.
-- PR chỉ tài liệu/nặng lockfile được chuẩn hóa để tránh thổi phồng kích thước.
+- Maintainer áp dụng nhãn `size:*` dựa trên số dòng thay đổi thực tế.
 
 ---
 
@@ -213,7 +204,7 @@ Chúng tôi **không** yêu cầu contributor định lượng quyền sở hữ
 - Mục tiêu triage maintainer đầu tiên: trong vòng 48 giờ.
 - Nếu PR bị chặn, maintainer để lại một checklist hành động được.
 - Tự động hóa `stale` được dùng để giữ hàng đợi lành mạnh; maintainer có thể áp dụng `no-stale` khi cần.
-- Tự động hóa `pr-hygiene` kiểm tra các PR mở mỗi 12 giờ và đăng nhắc nhở khi PR không có commit mới trong 48+ giờ và hoặc là đang tụt hậu so với `main` hoặc thiếu/thất bại `CI Required Gate` trên head commit.
+- Maintainer định kỳ kiểm tra các PR cũ cần rebase hoặc chạy lại CI check.
 
 ### 8.1 Kiểm soát ngân sách hàng đợi
 
@@ -229,13 +220,7 @@ Chúng tôi **không** yêu cầu contributor định lượng quyền sở hữ
 
 - `r:needs-repro` cho báo cáo lỗi chưa đầy đủ (yêu cầu repro mang tính quyết định trước khi triage sâu).
 - `r:support` cho các mục sử dụng/trợ giúp nên xử lý ngoài bug backlog.
-- Nhãn `invalid` / `duplicate` kích hoạt tự động hóa đóng **chỉ issue** kèm hướng dẫn.
-
-### 8.4 Bảo vệ tác dụng phụ của tự động hóa
-
-- `PR Auto Responder` loại bỏ trùng lặp comment dựa trên nhãn để tránh spam.
-- Các luồng đóng tự động chỉ giới hạn cho issue, không phải PR.
-- Maintainer có thể đóng băng tính toán lại rủi ro tự động bằng `risk: manual` khi ngữ cảnh yêu cầu ghi đè thủ công.
+- `duplicate` / `invalid` cho các mục không thể hành động.
 
 ---
 
@@ -270,7 +255,7 @@ Các thay đổi ở những khu vực này yêu cầu review chặt chẽ hơn
 
 Nếu một PR đã merge gây ra hồi quy:
 
-1. Revert PR ngay lập tức trên `main`.
+1. Revert PR ngay lập tức trên `master`.
 2. Mở issue theo dõi với phân tích nguyên nhân gốc.
 3. Chỉ đưa lại bản sửa lỗi khi có test hồi quy.
 
@@ -281,8 +266,7 @@ Nếu một PR đã merge gây ra hồi quy:
 ## 11. Checklist merge của maintainer
 
 - Phạm vi tập trung và dễ hiểu.
-- CI gate đã xanh.
-- Kiểm tra chất lượng tài liệu đã xanh khi tài liệu thay đổi.
+- CI check đã xanh (`test` + `build`).
 - Các trường tác động bảo mật đã hoàn thành.
 - Các trường tính riêng tư/vệ sinh dữ liệu đã hoàn thành và bằng chứng đã được biên tập/ẩn danh.
 - Ghi chú workflow agent đủ để tái tạo (nếu tự động hóa được sử dụng).
@@ -298,7 +282,7 @@ Nếu một PR đã merge gây ra hồi quy:
 ### 12.1 Làn A: triage nhanh (thân thiện với agent)
 
 - Xác nhận độ đầy đủ của template PR.
-- Xác nhận tín hiệu CI gate (`CI Required Gate`).
+- Xác nhận CI check pass (`test` + `build`).
 - Xác nhận phân loại rủi ro qua nhãn và các đường dẫn đã chạm.
 - Xác nhận tuyên bố rollback tồn tại.
 - Xác nhận phần tính riêng tư/vệ sinh dữ liệu và các yêu cầu diễn đạt trung lập đã được thỏa mãn.

docs/vi/release-process.md

@@ -2,111 +2,94 @@
 
 Runbook này định nghĩa quy trình release tiêu chuẩn của maintainer.
 
-Cập nhật lần cuối: **2026-02-20**.
+Cập nhật lần cuối: **2026-03-06**.
 
-## Mục tiêu release
+## Mục tiêu Release
 
-- Đảm bảo release có thể dự đoán và lặp lại.
-- Chỉ publish từ code đã có trên `main`.
-- Xác minh các artifact đa nền tảng trước khi publish.
-- Duy trì nhịp release đều đặn ngay cả khi PR volume cao.
+- Giữ release có thể dự đoán và lặp lại.
+- Chỉ publish từ code đã có trên `master`.
+- Xác minh artifact đa target trước khi publish.
+- Giữ cadence release đều đặn ngay cả khi khối lượng PR cao.
 
-## Chu kỳ tiêu chuẩn
+## Mô hình Release
+
+ZeroClaw sử dụng mô hình release hai tầng:
+
+- **Beta release** tự động — mỗi merge vào `master` kích hoạt beta pre-release (`vX.Y.Z-beta.<run_number>`).
+- **Stable release** thủ công — maintainer chạy `Promote Release` qua workflow dispatch để cắt phiên bản non-pre-release.
+
+## Hợp đồng Workflow
+
+Tự động hóa release nằm trong:
+
+- `.github/workflows/release.yml` — beta release tự động khi push lên `master`
+- `.github/workflows/promote-release.yml` — stable release thủ công qua workflow dispatch
+
+### Beta Release (tự động)
+
+- Kích hoạt trên mỗi push lên `master`.
+- Tính version từ `Cargo.toml`: `vX.Y.Z-beta.<run_number>`.
+- Build ma trận 5 target (linux x86_64/aarch64, macOS x86_64/aarch64, Windows x86_64).
+- Publish GitHub pre-release với archives + SHA256SUMS.
+- Build và push Docker image đa nền tảng lên GHCR (`beta` + version tag).
+
+### Stable Release (thủ công)
+
+- Kích hoạt qua `workflow_dispatch` với input `version` (ví dụ `0.2.0`).
+- Xác thực version khớp `Cargo.toml` và tag chưa tồn tại.
+- Build cùng ma trận 5 target như beta.
+- Publish GitHub stable release với archives + SHA256SUMS.
+- Build và push Docker image lên GHCR (`latest` + version tag).
+
+## Quy trình Maintainer
+
+### 1) Kiểm tra trước trên `master`
+
+1. Đảm bảo CI xanh trên `master` mới nhất.
+2. Xác nhận không có incident ưu tiên cao hoặc regression đã biết đang mở.
+3. Xác nhận các beta release gần đây khỏe mạnh (kiểm tra trang GitHub Releases).
+
+### 2) Tùy chọn: chạy CI Full Matrix
+
+Nếu xác minh cross-compilation trước stable release:
+
+- Chạy `CI Full Matrix` thủ công (`.github/workflows/ci-full.yml`).
+- Xác nhận build thành công trên `aarch64-unknown-linux-gnu`, `x86_64-apple-darwin` và `x86_64-pc-windows-msvc`.
+
+### 3) Tăng version trong `Cargo.toml`
+
+1. Tạo branch, cập nhật `version` trong `Cargo.toml` lên version mục tiêu.
+2. Mở PR, merge vào `master`.
+3. Merge kích hoạt beta release tự động.
+
+### 4) Promote lên stable release
+
+1. Chạy workflow `Promote Release` thủ công:
+   - `version`: version mục tiêu (ví dụ `0.2.0`) — phải khớp `Cargo.toml`
+2. Workflow xác thực version, build tất cả target và publish.
+
+### 5) Xác thực sau release
+
+1. Xác minh asset GitHub Release có thể tải.
+2. Xác minh GHCR tag cho version đã release.
+3. Xác minh đường dẫn cài đặt dựa trên release asset (ví dụ tải binary bootstrap).
+
+## Cadence Tiêu chuẩn
 
 - Release patch/minor: hàng tuần hoặc hai tuần một lần.
-- Bản vá bảo mật khẩn cấp: out-of-band.
-- Không bao giờ chờ tích lũy quá nhiều commit lớn.
+- Sửa bảo mật khẩn cấp: ngoài lịch trình.
+- Beta release ship liên tục với mỗi merge.
 
-## Hợp đồng workflow
+## Đường dẫn Khẩn cấp / Khôi phục
 
-Automation release nằm tại:
+Nếu stable release thất bại:
 
-- `.github/workflows/pub-release.yml`
+1. Sửa vấn đề trên `master`.
+2. Chạy lại `Promote Release` với cùng version (nếu tag chưa được tạo).
+3. Nếu tag đã tồn tại, tăng lên patch version tiếp theo.
 
-Các chế độ:
+## Ghi chú Vận hành
 
-- Tag push `v*`: chế độ publish.
-- Manual dispatch: chế độ chỉ xác minh hoặc publish.
-- Lịch hàng tuần: chế độ chỉ xác minh.
-
-Các guardrail ở chế độ publish:
-
-- Tag phải khớp định dạng semver-like `vX.Y.Z[-suffix]`.
-- Tag phải đã tồn tại trên origin.
-- Commit của tag phải có thể truy vết được từ `origin/main`.
-- GHCR image tag tương ứng (`ghcr.io/<owner>/<repo>:<tag>`) phải sẵn sàng trước khi GitHub Release publish hoàn tất.
-- Artifact được xác minh trước khi publish.
-
-## Quy trình maintainer
-
-### 1) Preflight trên `main`
-
-1. Đảm bảo các required check đều xanh trên `main` mới nhất.
-2. Xác nhận không có sự cố ưu tiên cao hoặc regression đã biết nào đang mở.
-3. Xác nhận các workflow installer và Docker đều khoẻ mạnh trên các commit `main` gần đây.
-
-### 2) Chạy verification build (không publish)
-
-Chạy `Pub Release` thủ công:
-
-- `publish_release`: `false`
-- `release_ref`: `main`
-
-Kết quả mong đợi:
-
-- Ma trận target đầy đủ build thành công.
-- `verify-artifacts` xác nhận tất cả archive mong đợi đều tồn tại.
-- Không có GitHub Release nào được publish.
-
-### 3) Cut release tag
-
-Từ một checkout cục bộ sạch đã sync với `origin/main`:
-
-```bash
-scripts/release/cut_release_tag.sh vX.Y.Z --push
-```
-
-Script này đảm bảo:
-
-- working tree sạch
-- `HEAD == origin/main`
-- tag không bị trùng lặp
-- định dạng tag semver-like
-
-### 4) Theo dõi publish run
-
-Sau khi push tag, theo dõi:
-
-1. Chế độ publish `Pub Release`
-2. Job publish `Pub Docker Img`
-
-Kết quả publish mong đợi:
-
-- release archive
-- `SHA256SUMS`
-- SBOM `CycloneDX` và `SPDX`
-- chữ ký/chứng chỉ cosign
-- GitHub Release notes + asset
-
-### 5) Xác minh sau release
-
-1. Xác minh GitHub Release asset có thể tải xuống.
-2. Xác minh GHCR tag cho phiên bản đã release và `latest`.
-3. Xác minh các đường dẫn cài đặt phụ thuộc vào release asset (ví dụ tải xuống binary bootstrap).
-
-## Đường dẫn khẩn cấp / khôi phục
-
-Nếu release push tag thất bại sau khi artifact đã được xác minh:
-
-1. Sửa vấn đề workflow hoặc packaging trên `main`.
-2. Chạy lại `Pub Release` thủ công ở chế độ publish với:
-   - `publish_release=true`
-   - `release_tag=<existing tag>`
-   - `release_ref` tự động được pin vào `release_tag` ở chế độ publish
-3. Xác minh lại asset đã release.
-
-## Ghi chú vận hành
-
-- Giữ các thay đổi release nhỏ và có thể đảo ngược.
-- Dùng một issue/checklist release cho mỗi phiên bản để bàn giao rõ ràng.
-- Tránh publish từ các feature branch ad-hoc.
+- Giữ thay đổi release nhỏ và có thể đảo ngược.
+- Ưu tiên một issue/checklist release cho mỗi version để handoff rõ ràng.
+- Tránh publish từ các branch tính năng tùy ý.

docs/vi/reviewer-playbook.md

@@ -81,7 +81,7 @@ Cho mỗi PR mới:
    - nhãn phạm vi (ví dụ `provider`, `channel`, `security`)
    - nhãn có phạm vi module (`channel:*`, `provider:*`, `tool:*`)
    - nhãn bậc contributor khi áp dụng được
-3. Xác nhận trạng thái tín hiệu CI (`CI Required Gate`).
+3. Xác nhận CI check pass (`test` + `build` từ `ci.yml`).
 4. Xác nhận phạm vi là một mối quan tâm (từ chối mega-PR hỗn hợp trừ khi có lý do).
 5. Xác nhận các yêu cầu tính riêng tư/vệ sinh dữ liệu và diễn đạt test trung lập đã được thỏa mãn.