docs: explain telegram package artifact testing

docs/ci.md

@@ -23,8 +23,9 @@ published npm spec, a trusted `package_ref` built with the selected
 from another GitHub Actions run, uploads it as `package-under-test`, then reuses
 the Docker release/E2E scheduler with that tarball instead of repacking the
 workflow checkout. Profiles cover smoke, package, product, full, and custom
-Docker lane selections. The optional Telegram lane is published-npm only and
-reuses the `NPM Telegram Beta E2E` workflow.
+Docker lane selections. The optional Telegram lane reuses the
+`package-under-test` artifact in the `NPM Telegram Beta E2E` workflow, with the
+published npm spec path kept for standalone dispatches.
 
 ## Package Acceptance
 

docs/help/testing.md

@@ -136,10 +136,13 @@ runs the same lanes before release approval.
     then seeds an affected broken session JSONL and verifies
     `openclaw doctor --fix` rewrites it to the active branch with a backup.
 - `pnpm test:docker:npm-telegram-live`
-  - Installs a published OpenClaw package in Docker, runs installed-package
+  - Installs an OpenClaw package candidate in Docker, runs installed-package
     onboarding, configures Telegram through the installed CLI, then reuses the
     live Telegram QA lane with that installed package as the SUT Gateway.
-  - Defaults to `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta`.
+  - Defaults to `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta`; set
+    `OPENCLAW_NPM_TELEGRAM_PACKAGE_TGZ=/path/to/openclaw-current.tgz` or
+    `OPENCLAW_CURRENT_PACKAGE_TGZ` to test a resolved local tarball instead of
+    installing from the registry.
   - Uses the same Telegram env credentials or Convex credential source as
     `pnpm openclaw qa telegram`. For CI/release automation, set
     `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex` plus
@@ -156,8 +159,8 @@ runs the same lanes before release approval.
   HTTPS tarball URL plus SHA-256, or tarball artifact from another run, uploads
   the normalized `openclaw-current.tgz` as `package-under-test`, then runs the
   existing Docker E2E scheduler with smoke, package, product, full, or custom
-  lane profiles. Published npm candidates can additionally run the Telegram QA
-  workflow.
+  lane profiles. Set `telegram_mode=mock-openai` or `live-frontier` to run the
+  Telegram QA workflow against the same `package-under-test` artifact.
   - Latest beta product proof:
 
 ```bash

docs/reference/RELEASING.md

@@ -112,7 +112,7 @@ the maintainer-only release runbook.
   SHA-256; or `source=artifact` for a tarball uploaded by another GitHub
   Actions run. The workflow resolves the candidate to
   `package-under-test`, reuses the Docker E2E release scheduler against that
-  tarball, and can optionally run published-npm Telegram QA.
+  tarball, and can optionally run Telegram QA against the same tarball.
   Example: `gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product`
   Common profiles:
   - `smoke`: install/channel/agent, gateway network, and config reload lanes
@@ -393,10 +393,10 @@ Common package profiles:
 - `full`: Docker release-path chunks with OpenWebUI
 - `custom`: exact `docker_lanes` list for focused reruns
 
-For post-publish beta proof, use `source=npm` with the exact beta package or
-`openclaw@beta`. Enable `telegram_mode=mock-openai` or
-`telegram_mode=live-frontier` only for published npm packages, because that
-path reuses the published-npm Telegram E2E workflow.
+For package-candidate Telegram proof, enable `telegram_mode=mock-openai` or
+`telegram_mode=live-frontier` on Package Acceptance. The workflow passes the
+resolved `package-under-test` tarball into the Telegram lane; the standalone
+Telegram workflow still accepts a published npm spec for post-publish checks.
 
 ## NPM workflow inputs