diff --git a/.openclaw-sync/source.json b/.openclaw-sync/source.json
index 1e30fab69..1011598ff 100644
--- a/.openclaw-sync/source.json
+++ b/.openclaw-sync/source.json
@@ -1,5 +1,5 @@
 {
   "repository": "openclaw/openclaw",
-  "sha": "eea7ba53455a85cf29a71bd2142c265ba228cfd6",
-  "syncedAt": "2026-04-14T16:14:23.304Z"
+  "sha": "27b14124d0fb7f5f4ef0bafb0877df07577d9a97",
+  "syncedAt": "2026-04-14T16:19:39.582Z"
 }
diff --git a/docs/reference/RELEASING.md b/docs/reference/RELEASING.md
index 42cc7cae5..777d63e2a 100644
--- a/docs/reference/RELEASING.md
+++ b/docs/reference/RELEASING.md
@@ -74,10 +74,10 @@ OpenClaw has three public release lanes:
   - real npm publish must pass a successful npm `preflight_run_id`
   - stable npm releases default to `beta`
   - stable npm publish can target `latest` explicitly via workflow input
-  - stable npm promotion from `beta` to `latest` is still available as an explicit manual mode on the trusted `OpenClaw NPM Release` workflow
-  - direct stable publishes can also run an explicit dist-tag sync mode that
-    points both `latest` and `beta` at the already-published stable version
-  - those dist-tag modes still need a valid `NPM_TOKEN` in the `npm-release` environment because npm `dist-tag` management is separate from trusted publishing
+  - token-based npm dist-tag mutation now lives in
+    `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
+    for security, because `npm dist-tag add` still needs `NPM_TOKEN` while the
+    public repo keeps OIDC-only publish
   - public `macOS Release` is validation-only
   - real private mac publish must pass successful private mac
     `preflight_run_id` and `validate_run_id`
@@ -116,10 +116,6 @@ OpenClaw has three public release lanes:
 - `preflight_run_id`: required on the real publish path so the workflow reuses
   the prepared tarball from the successful preflight run
 - `npm_dist_tag`: npm target tag for the publish path; defaults to `beta`
-- `promote_beta_to_latest`: `true` to skip publish and move an already-published
-  stable `beta` build onto `latest`
-- `sync_stable_dist_tags`: `true` to skip publish and point both `latest` and
-  `beta` at an already-published stable version
 
 `OpenClaw Release Checks` accepts these operator-controlled inputs:
 
@@ -134,14 +130,6 @@ Rules:
 - Release checks commit-SHA mode also requires the current `origin/main` HEAD
 - The real publish path must use the same `npm_dist_tag` used during preflight;
   the workflow verifies that metadata before publish continues
-- Promotion mode must use a stable or correction tag, `preflight_only=false`,
-  an empty `preflight_run_id`, and `npm_dist_tag=beta`
-- Dist-tag sync mode must use a stable or correction tag,
-  `preflight_only=false`, an empty `preflight_run_id`, `npm_dist_tag=latest`,
-  and `promote_beta_to_latest=false`
-- Promotion and dist-tag sync modes also require a valid `NPM_TOKEN` because
-  `npm dist-tag add` still needs regular npm auth; trusted publishing covers
-  the package publish path only
 
 ## Stable npm release sequence
 
@@ -159,17 +147,16 @@ When cutting a stable npm release:
 4. Save the successful `preflight_run_id`
 5. Run `OpenClaw NPM Release` again with `preflight_only=false`, the same
    `tag`, the same `npm_dist_tag`, and the saved `preflight_run_id`
-6. If the release landed on `beta`, run `OpenClaw NPM Release` later with the
-   same stable `tag`, `promote_beta_to_latest=true`, `preflight_only=false`,
-   `preflight_run_id` empty, and `npm_dist_tag=beta` when you want to move that
-   published build to `latest`
+6. If the release landed on `beta`, use the private
+   `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
+   workflow to promote that stable version from `beta` to `latest`
 7. If the release intentionally published directly to `latest` and `beta`
-   should follow the same stable build, run `OpenClaw NPM Release` with the same
-   stable `tag`, `sync_stable_dist_tags=true`, `promote_beta_to_latest=false`,
-   `preflight_only=false`, `preflight_run_id` empty, and `npm_dist_tag=latest`
+   should follow the same stable build immediately, use that same private
+   workflow to point both dist-tags at the stable version, or let its scheduled
+   self-healing sync move `beta` later
 
-The promotion and dist-tag sync modes still require the `npm-release`
-environment approval and a valid `NPM_TOKEN` accessible to that workflow run.
+The dist-tag mutation lives in the private repo for security because it still
+requires `NPM_TOKEN`, while the public repo keeps OIDC-only publish.
 
 That keeps the direct publish path and the beta-first promotion path both
 documented and operator-visible.