Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/controller/openapi.json`:
- Around line 3359-3376: The OpenAPI request bodies for the new onboarding POST
endpoints currently omit requestBody.required making the entire body optional;
update the OpenAPI generation (the POST route specs that include a requestBody
with properties like "botToken" and "accountId") to set requestBody.required:
true so the body itself is required while keeping the inner property
"botToken"/"accountId" required as-is; apply the same change for the other two
occurrences referenced (the blocks around the "botToken" schema and the ones at
the other two ranges) so all POST onboarding routes enforce a required request
body.

In `@apps/controller/src/services/channel-service.ts`:
- Around line 469-485: fetchWechatQrCode uses a bare fetch so a stalled upstream
can hang wechatQrStart; add an AbortController-based timeout: create an
AbortController inside fetchWechatQrCode, start a timer (e.g., 10s or use a
configurable constant) that calls controller.abort(), pass controller.signal to
fetch(url.toString(), { signal }), and clear the timer after fetch completes;
ensure the function throws a clear timeout/abort error so callers (like
wechatQrStart) can handle it.
- Around line 681-690: The polling loop in channel-service.ts that calls
pollWechatQrStatus (using DEFAULT_WECHAT_BASE_URL and activeLogin.qrcode) spins
with no delay when status is "wait" or "scaned"; add a short awaitable backoff
inside that branch (e.g., await sleep(500ms) with optional exponential/backoff
capped at ~5s and jitter) so the loop yields between requests and reduces
hammering the WeChat API, leaving the existing deadline logic intact; implement
a small helper like sleep(ms) and apply it whenever status is "wait" or "scaned"
before continuing.

In `@apps/controller/src/store/nexu-config-store.ts`:
- Around line 852-868: The update block in this.store.update that replaces
channels by channelType+accountId leaves orphaned secrets keyed by the previous
channel.id (e.g., channel:<oldId>:botToken or channel:<oldId>:authDir) causing
unreachable secrets after reconnect; modify the update logic in the
channels-replacement blocks (the this.store.update call that builds channels and
secrets using channel and input) to detect any previous channel with the same
channelType+accountId, and remove its secrets from the secrets map (delete keys
like `channel:${oldId}:botToken` and `channel:${oldId}:authDir`) while adding
the new `channel:${channel.id}:...` entries; apply the same pruning change to
the second occurrence of this pattern (the other this.store.update block around
the 892-910 region).

In `@apps/controller/static/runtime-plugins/whatsapp/package.json`:
- Around line 7-10: The package.json "openclaw.extensions" currently points to
"./index.ts" but the plugin isn't compiled, so Node will fail to load it; add a
build step to transpile TypeScript to JavaScript (e.g., add a "build" script
using tsc or an equivalent bundler), ensure the compiled output includes an
"index.js" at the same path, and update package.json or the
"openclaw.extensions" entry if you change the output path; specifically modify
the plugin's package.json to add a "scripts.build" (and run it in CI) and ensure
the source entry referenced by openclaw (the "extensions" array) points to the
produced index.js rather than index.ts.

In `@apps/controller/static/runtime-plugins/whatsapp/src/channel.ts`:
- Around line 246-264: listActions currently may add "poll" to the returned set
via createActionGate(cfg.channels.whatsapp.actions) but supportsAction and
handleAction only accept "react", causing a mismatch; either remove "poll" from
listActions or implement poll support. Fix by updating listActions in the
whatsapp channel to not add "poll" (remove gate("poll") / actions.add("poll"))
if you do not intend to support polls, or by extending supportsAction to return
true for "poll" and adding a poll handling branch in handleAction (similar to
the existing react branch) that validates params, performs the poll action
against the provider, and throws a clear error including meta.id on unsupported
action. Ensure consistency between listActions, supportsAction, and handleAction
for ChannelMessageActionName values so "poll" is only present if fully
supported.
- Around line 407-427: buildAccountSnapshot currently forces configured: true
which contradicts the linked check and makes resolveAccountState report "linked"
for unlinked accounts; change buildAccountSnapshot (the function that calls
getWhatsAppRuntime().channel.whatsapp.webAuthExists and sets linked) to set
configured to the actual link status (e.g., configured: !!linked or configured:
linked) or otherwise derive it from account.authDir/webAuthExists instead of
hardcoding true so resolveAccountState correctly reflects the account's real
auth state.

In `@apps/desktop/main/services/launchd-bootstrap.ts`:
- Around line 686-702: Currently openclawBinPath and openclawExtensionsDir point
at .tmp/sidecars/openclaw while openclawPath still points at
openclaw-runtime/node_modules, causing mismatched installs; unify by deriving
all OpenClaw locations from a single sidecar root variable (e.g., const
openclawSidecarRoot = path.join(repoRoot, ".tmp", "sidecars", "openclaw")) and
then set openclawBinPath, openclawExtensionsDir and openclawPath from that root
(e.g., openclawPath -> path.join(openclawSidecarRoot, "node_modules",
"openclaw", "openclaw.mjs")), and replace existing hardcoded paths in the return
object so controller and gateway use the same OpenClaw install.
- Around line 656-662: resolveLaunchdPaths() is computing openclawSidecarRoot
from ~/.nexu which differs from the runtime manifest resolver; update
resolveLaunchdPaths to accept (or derive) the same runtime/userData root used by
the manifest resolver (the same runtimeRoot value) and build openclawBinPath and
openclawExtensionsDir from that shared root instead of openclawSidecarRoot
derived from ~/.nexu; adjust the function signature/call sites to pass through
the runtimeRoot so openclawBinPath and openclawExtensionsDir reference the exact
packaged sidecar the manifests.ts resolver uses.

In `@apps/web/src/components/channel-setup/telegram-setup-view.tsx`:
- Around line 22-23: The hard-coded English strings in telegram-setup-view.tsx
(all toast messages, headings, helper text, step descriptions, labels, and
button text used in the Telegram setup UI and in functions that call
toast.error) must be moved to i18n translation keys: wrap the component with
react-i18next's useTranslation and replace every literal string (including the
toast.error("Telegram bot token is required") call and all UI text in the
component) with t('channelSetup.telegram.<descriptive_key>') lookups; add
corresponding keys/values to the appropriate locale resource files, and ensure
the toast calls use those translated strings (e.g.,
toast.error(t('channelSetup.telegram.tokenRequired'))), so the entire onboarding
experience is localized.
- Around line 32-37: The toast currently displays raw error.message from the
Telegram connect flow (in telegram-setup-view.tsx around the if (error || !data)
block), which can leak bot tokens or upstream URLs; change this to always show a
generic user-facing message (e.g. "Failed to connect to Telegram") or map only
from a strict allowlist of safe error keys before touching the toast, and ensure
any full error details are only logged to a secure developer log (not shown to
the user) or sent to server-side telemetry instead; update the logic that
computes message (the variable currently derived from error.message) and the
toast.error call accordingly while keeping any sensitive error content out of
the UI.

In `@apps/web/src/components/channel-setup/whatsapp-setup-view.tsx`:
- Around line 44-73: finalizeConnect currently treats a non-terminal `/qr-wait`
response as an immediate error and lets its async work continue after the modal
is closed; update finalizeConnect (and the related polling flow around
postApiV1ChannelsWhatsappConnect) to treat responses where connected === false
as a cancellable polling step (do not setPhase("error") or drop QR prematurely),
implement cancellation via an AbortController or by checking mountedRef.current
before any state mutations, and ensure any pending promise early-returns when
cancelled; specifically, modify the code path that inspects the API
error/response from postApiV1ChannelsWhatsappConnect to continue polling on
qr-wait responses, only transition to "error" on real terminal errors, and guard
all setPhase/setQrUrl/onConnected calls with mountedRef.current or abort checks
to prevent background updates after the modal is closed.

In `@apps/web/src/pages/channels.tsx`:
- Around line 452-475: The Telegram card renders several hard-coded English
strings; update the JSX block that checks platform === "telegram" and
telegramBotUrl to use the i18n translator (t(...)) for all user-facing text
(title "Open in Telegram", description lines, button label "Open Bot") instead
of raw strings, keeping the same structure and components (ExternalLink, anchor
props, classNames, etc.), and add corresponding translation keys to the locale
files used by the app so the strings are available in other locales.
- Around line 334-337: The inline Telegram URL construction using
channel.botUserId should be replaced with the shared helper getChannelChatUrl to
preserve the existing Telegram Web fallback and handle missing botUserId; find
the telegramBotUrl declaration (currently using platform === "telegram" &&
channel.botUserId) and set telegramBotUrl = getChannelChatUrl(...) using the
helper's expected parameters (pass platform and/or channel object as the helper
requires) so the helper centralizes the URL logic for Telegram channels.

In `@apps/web/src/pages/home.tsx`:
- Around line 1120-1178: TelegramModal and WhatsappModal are missing the
accessibility contract that WechatQrModal uses; update both components to behave
like real dialogs by adding role="dialog" and aria-modal="true" on the outer
dialog container, give the title element a unique id and reference it with
aria-labelledby, add an accessible label (e.g. aria-label="Close dialog") to the
icon-only close button, and implement Escape key and backdrop-click handlers to
call onClose (and ensure focus is moved into and trapped within the modal on
open and restored on close similar to WechatQrModal). Use the same identifying
symbols (TelegramModal, WhatsappModal, the close button and the title div /
TelegramSetupView / WhatsappSetupView) so the changes mirror the existing
WechatQrModal accessibility behavior.

---

Nitpick comments:
In `@apps/controller/src/store/nexu-config-store.ts`:
- Around line 839-840: The code creates new channel IDs using
crypto.randomUUID() for the ChannelResponse objects (variable channel) — replace
those calls with the cuid2 generator from `@paralleldrive/cuid2` (e.g.,
createId()) so the exposed ChannelResponse IDs follow the repo’s public-id rule;
add the import for createId and update both occurrences (the channel
construction at the current snippet and the other occurrence around lines
879-880) to use createId() instead of crypto.randomUUID().

In `@apps/controller/static/runtime-plugins/whatsapp/src/channel.ts`:
- Around line 439-441: Current startup log interpolates account metadata into a
single string; change it to emit structured fields and a short message instead.
In the block using
getWhatsAppRuntime().channel.whatsapp.readWebSelfId(account.authDir) and
ctx.log?.info, build a log call that passes an object with accountId, e164, jid
(omit sensitive values if they are credentials) and a concise message like
"starting provider" rather than embedding them in the message string; update the
call site where account.accountId, e164, and jid are used (and ensure you never
log secrets) so downstream log consumers can query fields instead of parsing the
interpolated string.

In `@apps/web/lib/api/types.gen.ts`:
- Around line 1-2: The generated types file produced by `@hey-api/openapi-ts` uses
4-space indentation and single quotes; update the generator configuration for
`@hey-api/openapi-ts` to emit double quotes and a 2-space indent (e.g., set quote
style to double and tabWidth/indentation to 2 in the generator’s options or
template/prettier settings), then regenerate the output (the header comment "//
This file is auto-generated by `@hey-api/openapi-ts`" identifies the generated
artifact to target).

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/controller/static/runtime-plugins/whatsapp/src/channel.ts`:
- Around line 437-448: The startup log in startAccount leaks WhatsApp
identifiers by logging e164 and jid returned from
getWhatsAppRuntime().channel.whatsapp.readWebSelfId(account.authDir); update the
ctx.log?.info invocation in startAccount to omit e164 and jid and log only
non-identifying context (e.g., channel: "whatsapp" and accountId:
account.accountId) so self IDs are not written to controller logs.

---

Outside diff comments:
In `@apps/controller/openapi.json`:
- Around line 2840-2847: The shared channelType schema is out of sync with the
OpenAPI contract — update the channelType enum in
packages/shared/src/schemas/channel.ts (both the schema definition and the
exported TypeScript union/type locations referencing channelType) to include
"telegram" and "whatsapp" alongside the existing values, ensure any
validators/types that reference channelType are updated accordingly, then
regenerate the OpenAPI and SDK artifacts so the spec and shared validators/types
match.

---

Duplicate comments:
In `@apps/controller/openapi.json`:
- Around line 3359-3376: The OpenAPI fragment omits requestBody.required which
leaves the entire JSON body optional despite properties like "botToken" and
"accountId" being required; update the OpenAPI generation logic to set
requestBody.required = true for the affected POST operations (the requestBody
objects that contain "botToken" and "accountId" schemas), regenerate
openapi.json, and ensure the regenerated spec includes requestBody.required:
true for the entries around the duplicated ranges (the ones shown with
"botToken" and the other POST bodies at the noted ranges).

In `@apps/controller/static/runtime-plugins/whatsapp/src/channel.ts`:
- Around line 407-427: In buildAccountSnapshot, configured is hardcoded to true
which misleads resolveAccountState; change configured to reflect the actual link
status (use the computed linked value or an explicit check like webAuthExists
result) so buildAccountSnapshot returns configured: linked (or equivalent) and
let resolveAccountState correctly return "linked" or "not linked".
- Around line 246-264: listActions returns "poll" but supportsAction and
handleAction only accept "react", causing callers to receive an advertised
action that will throw; either stop advertising "poll" or implement poll
handling. Update either listActions (in the same channel.ts code) to omit adding
"poll" from the actions Set when gate("polls") is true, or modify supportsAction
to return action === "react" || action === "poll" and extend handleAction to
branch on action === "poll" (or delegate to a new handlePoll function) and avoid
throwing for poll; reference the functions listActions, supportsAction,
handleAction and the meta.id error message to keep behavior consistent.

---

Nitpick comments:
In `@apps/controller/src/store/nexu-config-store.ts`:
- Line 844: The code is using crypto.randomUUID() for public channel IDs (e.g.
the object property "id: crypto.randomUUID()") which conflicts with the
guideline to use `@paralleldrive/cuid2` for public IDs; replace the
crypto.randomUUID() calls used to generate public IDs with the cuid2 generator
(import { createId } from '@paralleldrive/cuid2') and use createId() wherever
"id: crypto.randomUUID()" appears (and the other similar occurrences around the
second instance) so public channel IDs are generated with cuid2; ensure imports
are added and remove or keep crypto import only if still needed for
private/internal IDs.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/controller/src/routes/channel-routes.ts`:
- Around line 324-358: The leading comment "WeChat QR login flow" above the
WhatsApp endpoint is stale and misleading; update or replace it to accurately
describe the code that follows (e.g., "WhatsApp QR login flow") where the
app.openapi(createRoute(...)) defines the POST route
"/api/v1/channels/whatsapp/qr-start" (and any adjacent WhatsApp routes),
ensuring nearby comments reflect that the WeChat flow actually begins later
around the WeChat handlers.

In `@apps/controller/src/services/channel-service.ts`:
- Around line 443-468: The loadWhatsappRuntimeModules function currently assumes
minified export names (sessionModule.t/i/r/n) exist; add runtime validation
after importing sessionModule to verify each expected export exists and is of
the correct type (e.g., typeof sessionModule.t === "function" for
createWaSocket, likewise for i, r, n) and if any check fails throw a clear,
descriptive error that includes the actual keys present on the imported module
and which expected export(s) were missing or invalid; reference sessionModule
and the mapping to createWaSocket/waitForWaConnection/getStatusCode/formatError
so reviewers can locate and update the validation and error message.

---

Nitpick comments:
In `@apps/controller/src/services/channel-service.ts`:
- Around line 889-960: The infinite loop uses while (true) and relies on
internal returns; change it to an explicit time-bound loop like while
(Date.now() < deadline) around the block that awaits Promise.race so the exit
condition is clear, keep the existing Promise.race/timeout logic and all
existing handling for login.error (including checks against
WHATSAPP_LOGGED_OUT_STATUS, calls to rmSync(login.authDir...),
resetActiveWhatsappLogin(accountId, ...), restartWhatsappLoginSocket(login,
runtime) and isWhatsappLoginFresh(login)), preserve the login.connected branch
(setting login.preserveAuthDirOnReset), and add a single fallback return after
the loop that returns { connected: false, message: "Still waiting for the QR
scan. Let me know when you've scanned it.", accountId } to cover any
fallthrough.
- Around line 778-866: The method whatsappQrStart currently calls
resetWhatsAppDefaultLoginState(...) unconditionally which deletes existing auth
and forces a fresh QR; add a concise code comment above that call (in
whatsappQrStart) explaining the rationale (e.g., to avoid stale or corrupted
credential state, ensure clean authDir before creating a new login session, and
prevent mismatched socket/auth state) and note any user-facing consequence
(users must re-scan) or future TODO if you intend to allow reuse; reference
resetWhatsAppDefaultLoginState, DEFAULT_WHATSAPP_ACCOUNT_ID, and the
authDir/login session logic so reviewers can see why the reset is necessary.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/controller/src/services/channel-service.ts`:
- Line 716: The polling deadline currently uses a hardcoded 500_000ms (deadline
= Date.now() + 500_000) which exceeds the QR code TTL; change the deadline
computation to use the WECHAT_LOGIN_TTL_MS constant (e.g., deadline = Date.now()
+ WECHAT_LOGIN_TTL_MS) in the function in channel-service.ts so polling stops
when the QR TTL elapses (or use Math.min if you need an upper bound), ensuring
the loop’s timeout aligns with WECHAT_LOGIN_TTL_MS.

---

Nitpick comments:
In `@apps/controller/src/services/channel-service.ts`:
- Around line 1066-1090: Extract the magic numbers in waitForWhatsappReady into
named constants: replace 45_000 with WHATSAPP_READINESS_TIMEOUT_MS and 1_500
with WHATSAPP_READINESS_POLL_INTERVAL_MS (define them near the other timeout
constants at top of the file), then update the function (method
waitForWhatsappReady) to use these constants for deadline calculation and the
sleep(...) call to keep consistency with existing timeout configuration.
- Line 911: The call to loadWhatsappRuntimeModules in whatsappQrWait causes
repeated FS and dynamic import work; add an instance-level cache and accessor to
avoid reloading: add a private field (e.g., whatsappRuntime:
WhatsappRuntimeModules | null = null) on the service, implement a private async
getWhatsappRuntime() that sets whatsappRuntime = await
loadWhatsappRuntimeModules(this.env) the first time and returns the cached
object thereafter, and update whatsappQrWait (and any other places calling
loadWhatsappRuntimeModules) to call getWhatsappRuntime() instead of
loadWhatsappRuntimeModules(this.env).
- Around line 555-561: The channel connection methods lack tracing annotations;
add `@Trace` or `@Span` decorators to the public methods that perform external calls
(e.g., connectTelegram, connectWhatsapp, whatsappQrStart, whatsappQrWait and any
other channel connect methods in ChannelService) so they emit
distributed-tracing spans; import the tracing decorators from the project's
tracing/tracer module, place an appropriate `@Trace/`@Span on each method, include
contextual attributes (channel type, channelId or phone) and ensure exceptions
are recorded on the span so errors are visible in monitoring.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/controller/src/services/channel-service.ts`:
- Around line 828-834: The code creates a temporary login session directory via
resolveWhatsAppLoginSessionDir and then uses its nested authDir (authDir,
loginSessionId, mkdirSync) as the channel's persistent auth state, which leaves
orphaned credentials when replaced; change this to persist a stable per-account
auth path (e.g., derive a deterministic auth path using the channel/account id
instead of the transient loginSessionId) or, if you must replace the stored
authDir in connectWhatsapp(), delete the previous authDir recursively before
assigning the new one (and update resetWhatsAppDefaultLoginState() to clear the
whole stored tree), referencing resolveWhatsAppLoginSessionDir,
connectWhatsapp(), resetWhatsAppDefaultLoginState(), authDir and loginSessionId
to locate the affected code.
- Around line 971-972: connectWhatsapp() must take responsibility for preserving
and rolling back auth-dir state: when preparing to store login.authDir
(including when login.connected is already true), set
login.preserveAuthDirOnReset = true before touching authDir and ensure you clear
it and call resetActiveWhatsappLogin() on failure; wrap the critical section
(including waitForWhatsappReady()) in try/catch/finally so any thrown error
triggers the rollback (unset preserveAuthDirOnReset and
resetActiveWhatsappLogin()), and remove reliance on whatsappQrWait() having set
preserveAuthDirOnReset first. Ensure the same change is applied to the other
block around lines 988-1008.
- Around line 736-748: The code uses status.ilink_bot_id without verifying
normalizeAccountId(status.ilink_bot_id) returns a non-empty string, so values
like "---" produce an empty normalizedAccountId and create a bad file; before
calling writeWeChatAccount and registerWeChatAccount, compute
normalizedAccountId = normalizeAccountId(status.ilink_bot_id) and skip (or
return/log) if normalizedAccountId is empty (e.g., === "" or falsy), ensuring
you only write/register when normalizedAccountId is a valid non-empty string.

---

Duplicate comments:
In `@apps/controller/src/services/channel-service.ts`:
- Around line 708-717: The polling deadline currently resets to Date.now() +
500_000 which can extend polling past the QR TTL; change the deadline
calculation in the wechat QR wait loop to use the QR's actual expiry
(activeLogin.startedAt + WECHAT_LOGIN_TTL_MS) and ensure you clamp it to at
least the current time (so you don't loop if already expired). Update the
variable referenced as deadline (used in the while loop that polls) to compare
against activeLogin.startedAt + WECHAT_LOGIN_TTL_MS instead of Date.now() +
500_000, keeping use of activeWechatLogins.delete(sessionKey) and the existing
early-return logic intact.

---

Nitpick comments:
In `@apps/controller/src/services/channel-service.ts`:
- Around line 676-695: The public sessionKey in wechatQrStart is generated with
randomUUID(), but this repo standard uses cuid2 for public IDs; replace
randomUUID() with the cuid2 generator (import createId from
'@paralleldrive/cuid2') and use createId() to produce sessionKey in the
wechatQrStart function, update the import list at the top of the file to include
createId, and keep the sessionKey variable name and usage unchanged so
activeWechatLogins and the returned object continue to work.