Summary

• WhatsApp lifecycle reactions: Wires StatusReactionController into the WhatsApp message turn, matching the existing Telegram and Discord implementations. When messages.statusReactions.enabled: true, the reaction on the trigger message cycles queued → thinking → tool → done/error (with stall warnings) instead of a single static ack emoji.
• New emoji categories across all channels (WhatsApp, Telegram, Discord):
  • deploy (🛫) — fastlane, ship, upload, testflight, deploy, release tokens
  • build (🏗️) — build, compile, xcode, swift, webpack, tsc, lint tokens
  • concierge (💁) — browser automation, puppeteer, playwright, chromedp, form-fill tokens
• Self-explanatory default emoji (Fixes Default status reaction emoji are unclear (🥱😨 for stalls) #59077): replaces the status reaction defaults that read as emotional commentary (🥱 yawn / 😨 fear / 🤔 / 🔥 / 👨‍💻 / 👍 / 😱) with universally readable status indicators. Folded in from the now-closed fix(channels): sync status reaction DEFAULT_EMOJIS with documented defaults #81762.
• Config schema updated: messages.statusReactions.emojis now accepts deploy, build, concierge keys in Zod schema, TypeScript types, and help text.

Status reaction default emoji (Fixes #59077)

Issue #59077 reported that the default status emoji read as mood rather than status — 🥱 → 😨 does not obviously mean "slow → stuck". New DEFAULT_EMOJIS:

compacting (✍), queued (👀), and the new deploy/build/concierge categories are unchanged.

Cross-platform check:

• Slack — UNICODE_TO_SLACK in extensions/slack/src/monitor/message-handler/dispatch.ts already maps every new emoji to a shortcode (brain, hammer_and_wrench, computer, globe_with_meridians, hourglass_flowing_sand, warning, white_check_mark, x).
• Telegram — Telegram only allows a fixed reaction set, and none of the new emoji are in it. The existing TELEGRAM_STATUS_REACTION_VARIANTS fallback lists handle this: resolveTelegramReactionVariant walks the per-state variant list and picks the first Telegram-supported emoji, so Telegram keeps rendering its supported equivalents. Graceful degradation, no behavior change on Telegram.
• Discord / WhatsApp / others — use raw unicode reactions; all new emoji are standard and valid as reactions.

Power users can still override any of these via messages.statusReactions.emojis in config.

Implementation details

New file: extensions/whatsapp/src/auto-reply/monitor/status-reaction.ts

• createWhatsAppStatusReactionController — mirrors the Telegram pattern; reuses the same ack eligibility gate (shouldAckReactionForWhatsApp) so the controller only activates when a reaction would have been sent anyway
• Adapter uses sendReactionWhatsApp(chatId, msgId, emoji) for status updates and a separate clear hook that sends sendReactionWhatsApp(chatId, msgId, "") only when removeAckAfterReply/clear explicitly asks to remove the single WhatsApp reaction slot

process-message.ts — creates controller before ack, calls setQueued() immediately; skips the plain ack when the controller is active

inbound-dispatch.ts — accepts optional statusReactionController, calls setThinking() before dispatch, wires onToolStart, onCompactionStart, onCompactionEnd callbacks, finalizes with setDone/setError/restoreInitial

on-message.ts — voice-note audio preflight starts the queued status reaction before STT when statusReactions.enabled, so slow transcription keeps the existing immediate receipt feedback

Real behavior proof

Behavior addressed: with this patch on a live WhatsApp link, inbound DMs trigger the StatusReactionController.setQueued() ack emoji immediately on receipt (before the agent's model call even begins), and the controller transitions emojis through queued → thinking → tool → done/error as the lifecycle advances. Prior to this patch the WhatsApp channel only ever set the static ack emoji via the maybeSendAckReaction path; reactions never cycled.

Real environment tested: macOS 25.2.0 (Darwin), Node 25.9.0, openclaw 2026.5.10-beta.1 HEAD 01cb2e41 (this PR's commit 9e1055f5 merged into a working branch on top of origin/main), built with pnpm build and rsynced into /opt/homebrew/lib/node_modules/openclaw/dist. Gateway runs as the ai.openclaw.gateway LaunchAgent linked to a personal WhatsApp Web account [redacted-whatsapp-account]. Sender handset is a second physical phone [redacted-sender-phone]. Config additions:

"messages": { "statusReactions": { "enabled": true } },
"channels": {
  "whatsapp": {
    "reactionLevel": "extensive",
    "ackReaction": { "emoji": "👀", "direct": true, "group": "mentions" }
  }
}

Exact steps or command run after the patch:

git checkout 01cb2e41                  // this PR (9e1055f5) merged on top of origin/main
pnpm build
rsync -a --delete dist/ /opt/homebrew/lib/node_modules/openclaw/dist/
launchctl kickstart -k gui/$(id -u)/ai.openclaw.gateway
// enable status reactions in ~/.openclaw/openclaw.json (block above)
// then sent a real WhatsApp DM "reaction test" from [redacted-sender-phone] to the bot

After-fix evidence (terminal output + screenshot):

1. Live gateway log (~/.openclaw/logs/gateway.log) — the WhatsApp adapter receives the inbound and the StatusReactionController's setQueued() immediately fires sendReactionWhatsApp, completing in ~33 ms:

2026-05-11T20:10:52.194+02:00 [whatsapp] Sending reaction "👀" -> message 3EB0E3BBB84D6CB0AFB647
2026-05-11T20:10:52.200+02:00 [whatsapp] Inbound message [redacted-sender-phone] -> [redacted-whatsapp-account] (direct, 79 chars)
2026-05-11T20:10:55.227+02:00 [whatsapp] Sent reaction "👀" -> message 3EB0E3BBB84D6CB0AFB647

A second inbound at 20:13 shows the same pattern, with the ack send completing in 28 ms:

2026-05-11T20:13:21.581+02:00 [whatsapp] Sending reaction "👀" -> message 3EB0BF9BC49DD814A3595B
2026-05-11T20:13:21.589+02:00 [whatsapp] Inbound message [redacted-sender-phone] -> [redacted-whatsapp-account] (direct, 1189 chars)
2026-05-11T20:13:21.609+02:00 [whatsapp] Sent reaction "👀" -> message 3EB0BF9BC49DD814A3595B

2. Recipient-side screenshot — WhatsApp app on the sender's iPhone showing the 👀 reaction overlaid on the user's "reaction test" message at 20:10 (delivered/read double check), with the bot's typing indicator below as the lifecycle continues into the setThinking() phase:

3. The reaction message id (3EB0E3BBB84D6CB0AFB647) is the WhatsApp stanza id of the user's outbound, exactly what sendReactionWhatsApp(chatId, msgId, "👀", { participant }) targets via Baileys' react: { key: {…} } content. The status-reaction adapter points every lifecycle update at the same id, so the recipient sees the emoji change in place rather than seeing multiple stacked reactions.

Observed result after fix: The ack emoji appears on the user's inbound within ~3 seconds of sending (network round-trip dominated). Before this patch, with the same config, no reaction ever appeared because the channel only had the plain maybeSendAckReaction path and statusReactions.enabled was a no-op for WhatsApp.

Repair proof after review: The review found that WhatsApp must not map shared per-emoji cleanup to an empty reaction because Baileys treats empty reaction text as removal of the current bot reaction. The adapter now exposes a single-slot clear hook, and src/channels/status-reactions.test.ts covers queued → thinking → done → restoreInitial without any empty clear call until explicit clear(). The review also found that voice notes lost pre-STT receipt feedback under messages.statusReactions.enabled; extensions/whatsapp/src/auto-reply/monitor/on-message.audio-preflight.test.ts now covers queued status reaction before STT and verifies the same controller is handed to processMessage.

What was not live-tested after review: The original live capture proves the queued WhatsApp reaction on a real link. The repair pass validated lifecycle cleanup, voice-note preflight ordering, Telegram fallback behavior, and dispatch wiring with targeted tests; it did not run a second live WhatsApp session.

Test plan

• Set messages.statusReactions.enabled: true with a WhatsApp account; send a message; verify queued ack appears — queued ack captured live, see proof section above
• pnpm test src/channels/status-reactions.test.ts src/channels/status-reactions.slack-lifecycle.test.ts extensions/telegram/src/status.test.ts — 78 tests passed after the Default status reaction emoji are unclear (🥱😨 for stalls) #59077 emoji-default change
• node scripts/run-vitest.mjs src/channels/status-reactions.test.ts extensions/whatsapp/src/auto-reply/monitor/on-message.audio-preflight.test.ts extensions/whatsapp/src/auto-reply/monitor/process-message.audio-preflight.test.ts extensions/telegram/src/bot-message-context.reactions.test.ts extensions/telegram/src/bot-message-dispatch.test.ts — 118 tests passed after the review fixes
• Verify Telegram reactions still work through fallback variants in extensions/telegram/src/bot-message-context.reactions.test.ts
• Verify new token categorization in src/channels/status-reactions.test.ts
• Verify plain ack still works when statusReactions.enabled is false/unset in WhatsApp audio preflight tests