Telegram E2E Userbot

Telegram E2E (Userbot)

Prove the requested behavior as a dedicated Telegram Test Server user. TDLib records edits, deletions, reactions, and typing that a second bot cannot observe. For visual claims, also inspect actual Telegram client screenshots; a reconstructed chat image or event log is not visual proof.

Each Convex credential contains one SUT bot and an independent authorization for the QA user. The runner owns that lease through readiness, proof, and cleanup. Pool creation, account authorization repair, and credential publication remain owner-only. Reversible test-chat setup with the leased QA user is ordinary proof work; preserve shared fixtures and other runs.

1. Prepare

Run from the OpenClaw checkout and ref under test, using its repository skill:

TELEGRAM_E2E_SKILL_DIR="${TELEGRAM_E2E_SKILL_DIR:-$PWD/.agents/skills/telegram-e2e-userbot}"
export TELEGRAM_E2E_SKILL_DIR

Verify node, uv, and a dependency-ready runtime for the exact ref before leasing a credential. The runner uses built dist/entry.js; --source-gateway uses the repository's development launcher when a dependency-ready source run is appropriate. It runs core and the Telegram plugin from TypeScript source; other plugins, including the model provider, use built output when it exists, so rebuild before claiming their changes. The live run must not implicitly install or build. Only the mock backend needs scripts/e2e/mock-openai-server.mjs.

Convex access can come from either:

• An existing authenticated CLI with access to the published broker deployment. From qa/convex-credential-broker, discovery tries convex, then bunx --no-install convex, then npx --offline --no --ignore-scripts convex. Each launcher gets one 15-second env --deployment <broker> get lookup for the CI secret. The helper uses the repository's existing broker binding; no local CONVEX_DEPLOYMENT, project-selection file, or dashboard lookup is needed. The secret stays in process memory.
• Both OPENCLAW_QA_CONVEX_SITE_URL and OPENCLAW_QA_CONVEX_SECRET_CI, supplied privately to the doctor or runner process by the existing credential owner.

Check available launchers, existing authentication, and broker-project access before declaring credentials missing. An authenticated launcher with no CI variable needs broker configuration, not another login. Ask the user for authentication only when no existing launcher can authenticate and the broker pair is unavailable. Do not install or log in on the user's behalf. A timeout or network failure is not evidence that credentials are missing. Bun's --no-install missing-binary error means that launcher is unavailable; discovery continues to the next installed launcher.

The standalone doctor needs no local HTTP listener, Gateway build, or model backend: it checks the leased TDLib user and calls Telegram’s official Test Bot API directly over HTTPS. The full scenario still needs local networking for its Gateway and Test Bot API adapter (including hold/reject controls), plus the mock provider when selected. A passing doctor does not qualify those local services.

For a full scenario on shared hosts, select two unused ports and pass them explicitly; the runner does not read port environment variables:

: "${TELEGRAM_GATEWAY_PORT:?set an unused Gateway port}"
: "${TELEGRAM_MOCK_PORT:?set an unused provider port}"

2. Select the proof

Read the verification map, then only the recipe for the behavior under test. Prefer a DM; use groups for group policy, mentions, commands, topics, or reactions. A generic success turn does not prove formatting, media, timing, or lifecycle behavior.

Extend the harness when its current actions or recorder fields cannot expose the claim. Scenario command actions can inspect the leased TDLib state, private credential file, Test Bot API proxy, and Gateway state. Use the runtime reference for timed scenarios, forums, photo/reply actions, non-default backends, manual operation, or failed-run recovery.