feat(messaging): add Zalo Bot API channel

[hunglp6d]

Summary

Adds Zalo (Bot API) as a messaging channel for sandboxed OpenClaw agents, built on the manifest-first messaging architecture (#3896). The channel renders the flat single-account channels.zalo config the upstream @openclaw/zalo plugin validates, ships a scoped zalo network policy preset, installs the plugin at image build, and runs an OpenClaw bridge-health check. Verified end-to-end on a live sandbox — the bot pairs, receives, and replies.

Related Issue

Part of #5492

Token Onboarding Guide

NemoClaw E2E Onboarding with Messaging Channels

Result

Changes

• New channel manifest src/lib/messaging/channels/zalo/manifest.ts — OpenClaw-only, token-paste auth, ZALO_BOT_TOKEN credential → {sandbox}-zalo-bridge provider, ZALO_ALLOWED_IDS DM allowlist, ZALO_GROUP_POLICY.
• Renders the flat channels.zalo shape (botToken/proxy/dmPolicy/allowFrom/groupPolicy) the @openclaw/zalo plugin expects — not the Telegram-style accounts.default nesting (which the plugin schema rejects).
• Template resolver channels/zalo/template-resolver.ts (proxy URL, allowlist, derived dmPolicy) and an OpenClaw bridge-health hook under channels/zalo/hooks/.
• New nemoclaw-blueprint/policies/presets/zalo.yaml allowing bot-api.zaloplatforms.com:443 (long-polling; no inbound webhook).
• Registered the manifest/resolver/hooks in built-ins.ts, channels/template-resolver.ts, hooks/builtins.ts; added zalo to agents/openclaw/manifest.yaml platforms.
• Widened selectManifests typing in metadata.ts to support the first OpenClaw-only channel.
• Updated channel/preset/provider/platform enumeration tests for the new channel.
• Docs: messaging channels, integration policy examples, commands reference (+ generated Hermes variant).

Type of Change

• Code change (feature, bug fix, or refactor)
• Code change with doc updates
• Doc only (prose changes, no code sample modifications)
• Doc only (includes code sample changes)

Verification

• PR description includes the DCO sign-off declaration and every commit appears as Verified in GitHub
• Git hooks passed during commit and push, or npx prek run --from-ref main --to-ref HEAD passes
• Targeted tests pass for changed behavior
• Full npm test passes (broad runtime changes only)
• Tests added or updated for new or changed behavior
• No secrets, API keys, or credentials committed
• Docs updated for user-facing behavior changes
• npm run docs builds without warnings (doc changes only)
• Doc pages follow the style guide (doc changes only)
• New doc pages include SPDX header and frontmatter (new pages only)

---

Signed-off-by: Hung Le hple@nvidia.com

Summary by CodeRabbit

• New Features

  • Added Zalo as a supported messaging platform, including full channel availability, enrollment preset, and runtime configuration for the OpenClaw agent.
  • Introduced Zalo-specific configuration, including bot token handling, allowlisted user IDs, group policy options, and bridge health hooks.

• Tests

  • Expanded the test suite to cover Zalo across channel manifests, templates, diagnostics, sandbox/sandbox-provider behavior, presets/policy listing, and compiled plan rendering.

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

Adds Zalo as a sixth built-in messaging channel for the OpenClaw agent. The change introduces a full channel manifest, a network policy preset for bot-api.zaloplatforms.com, a template resolver, bridge health hook wiring, and registers Zalo in all relevant built-in registries. Test suites are updated throughout to cover the new channel.

Changes

Zalo Channel Integration

Layer / File(s)	Summary
Zalo manifest and network policy preset src/lib/messaging/channels/zalo/manifest.ts, nemoclaw-blueprint/policies/presets/zalo.yaml, agents/openclaw/manifest.yaml, src/lib/messaging/channels/built-ins.ts, src/lib/messaging/channels/metadata.ts	Defines the full zaloManifest with token-paste auth, enrollment inputs (bot token, allowed IDs, group policy), OpenClaw JSON render fragments, state persistence, and hook registrations. Adds the network policy preset allowing GET/POST to bot-api.zaloplatforms.com:443. Registers zaloManifest in BUILT_IN_CHANNEL_MANIFESTS and adds zalo to the agent's supported platforms list.
Zalo template resolver and hook registrations src/lib/messaging/channels/zalo/template-resolver.ts, src/lib/messaging/channels/template-resolver.ts, src/lib/messaging/channels/zalo/hooks/openclaw-bridge-health.ts, src/lib/messaging/channels/zalo/hooks/index.ts, src/lib/messaging/hooks/builtins.ts	Adds resolveZaloTemplateReference for proxy URL, allowed user IDs, DM policy, and group policy resolution, registering it in BUILT_IN_TEMPLATE_REFERENCE_RESOLVERS. Adds createZaloOpenClawBridgeHealthHookRegistration and createZaloHookRegistrations, wiring them into BuiltInMessagingHookOptions and createBuiltInMessagingHookRegistrations.
Unit and integration test updates src/lib/messaging/channels/manifests.test.ts, src/lib/messaging/channels/metadata.test.ts, src/lib/messaging/compiler/manifest-compiler.test.ts, test/channels-add-preset.test.ts, src/lib/messaging/hooks/hook-runner.test.ts, src/lib/sandbox/channels.test.ts, test/policies.test.ts, test/sandbox-provider-cleanup.test.ts, src/lib/messaging/diagnostics.test.ts, src/lib/onboard/messaging-prep.test.ts, src/lib/messaging-channel-config.test.ts, src/lib/agent/defs.test.ts	Extends assertions across all affected test suites to include zalo: channel IDs, env keys (ZALO_BOT_TOKEN, ZALO_ALLOWED_IDS, ZALO_GROUP_POLICY), hook ID (zalo.openclawBridgeHealth), render shape, credential bindings, build steps, health checks, policy preset list, and provider suffix zalo-bridge.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related issues

• feat(messaging): onboard additional experimental messaging channels #5492: This PR directly implements the Zalo built-in messaging channel tracked as in-progress in that issue.

Possibly related PRs

• NVIDIA/NemoClaw#5135: Both PRs modify prepareCreateSandboxMessaging test expectations; this PR adds ZALO_BOT_TOKEN to the same assertion updated in that refactor.
• NVIDIA/NemoClaw#5338: This PR extends the same BUILT_IN_CHANNEL_MANIFESTS array and built-in hook registration plumbing introduced by that manifest-driven messaging refactor.
• NVIDIA/NemoClaw#5463: This PR's metadata test updates (managed channel names, env key derivation) depend on the channel metadata helpers added in that PR.

Suggested labels

integration: openclaw

Suggested reviewers

• cv

🐇 A new friend hops onto the wire,
Zalo joins the channel choir!
Bot token pasted, policy set,
allowlist guards each DM yet.
From Telegram to Zalo's light —
six channels strong, the stack feels right! 🌟

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 7.14% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'feat(messaging): add Zalo Bot API channel' clearly and specifically summarizes the primary change—adding Zalo as a new messaging channel to the system.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/messaging-channel-zalo

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-code-quality]

Code Coverage Overview

Languages: TypeScript

TypeScript / code-coverage/plugin

The overall coverage in the feat/messaging-chann... branch is 96%. Coverage data for the main branch is not yet available.

Show a code coverage summary of the most covered files.

File	main	feat/messaging-chann... 950f538	+/-
nemoclaw/src/se...cret-scanner.ts	—	100%	—
nemoclaw/src/commands/slash.ts	—	100%	—
nemoclaw/src/li...bprocess-env.ts	—	100%	—
nemoclaw/src/bl...eprint/state.ts	—	98%	—
nemoclaw/src/onboard/config.ts	—	98%	—
nemoclaw/src/bl...int/snapshot.ts	—	97%	—
nemoclaw/src/bl...print/runner.ts	—	95%	—
nemoclaw/src/co...ration-state.ts	—	94%	—
nemoclaw/src/bl...ate-networks.ts	—	94%	—
nemoclaw/src/index.ts	—	94%	—

TypeScript / code-coverage/cli

The overall coverage in the feat/messaging-chann... branch is 47%. Coverage data for the main branch is not yet available.

Show a code coverage summary of the most covered files.

File	main	feat/messaging-chann... 950f538	+/-
src/lib/state/o...oard-session.ts	—	91%	—
src/lib/inference/local.ts	—	76%	—
src/lib/sandbox/config.ts	—	72%	—
src/lib/actions...dbox/rebuild.ts	—	71%	—
src/lib/onboard/preflight.ts	—	64%	—
src/lib/actions...licy-channel.ts	—	60%	—
src/lib/state/sandbox.ts	—	55%	—
src/lib/policy/index.ts	—	49%	—
src/lib/onboard...er-gpu-patch.ts	—	44%	—
src/lib/onboard.ts	—	19%	—

---

_{Updated June 25, 2026 18:48 UTC
Code Coverage is in Public Preview. Learn more and provide us with your feedback.}

[github-actions]

🌿 Preview your docs: https://nvidia-preview-pr-5583.docs.buildwithfern.com/nemoclaw

[github-actions]

PR Review Advisor — Blocked

Merge posture: Do not merge until addressed
Primary next action: Fix PRA-3: Zalo-specific assertions still grow aggregate test hotspots; then add or justify PRA-T1.
Open items: 1 required · 6 warnings · 0 suggestions · 8 test follow-ups
Since last review: 0 prior items resolved · 7 still apply · 0 new items found

Action checklist

• PRA-3 Fix: Zalo-specific assertions still grow aggregate test hotspots in src/lib/messaging/channels/manifests.test.ts:666
• PRA-1 Resolve or justify: Source-of-truth review needed: ZALO_ALLOWED_IDS persisted config and render path
• PRA-2 Resolve or justify: Source-of-truth review needed: Zalo Bot API policy path scope
• PRA-4 Resolve or justify: Persisted Zalo allowlists can bypass the manifest ID format check in src/lib/messaging-channel-config.ts:13
• PRA-5 Resolve or justify: Zalo policy grants GET and POST to every Bot API path in nemoclaw-blueprint/policies/presets/zalo.yaml:18
• PRA-6 Resolve or justify: User-facing messaging docs still omit Zalo in docs/manage-sandboxes/messaging-channels.mdx:5
• PRA-7 Resolve or justify: Runtime/build validation is still needed for the new Zalo sandbox path in src/lib/messaging/channels/zalo/manifest.ts:129
• PRA-T1 Add or justify test follow-up: Runtime validation
• PRA-T2 Add or justify test follow-up: Runtime validation
• PRA-T3 Add or justify test follow-up: Runtime validation
• PRA-T4 Add or justify test follow-up: Runtime validation
• PRA-T5 Add or justify test follow-up: Runtime validation
• PRA-T6 Add or justify test follow-up: Runtime/build validation is still needed for the new Zalo sandbox path
• PRA-T7 Add or justify test follow-up: Acceptance clause
• PRA-T8 Add or justify test follow-up: Acceptance clause

Findings index

ID	Severity	Category	Location	Required action
PRA-1	Resolve/justify	architecture	—	Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
PRA-2	Resolve/justify	architecture	—	Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
PRA-3	Required	architecture	src/lib/messaging/channels/manifests.test.ts:666	Shrink the aggregate tests to registration/order and shared cross-channel invariants. Move Zalo flat `channels.zalo` render, absence of `accounts`, pinned `npm:@openclaw/zalo@{{openclaw.version}}`, provider placeholder, hook registration, group policy, allowlist rendering, and compiled output assertions into focused Zalo test files.
PRA-4	Resolve/justify	security	src/lib/messaging-channel-config.ts:13	Fix the source boundary by carrying manifest `formatPattern` into `normalizeMessagingChannelConfigValue()` for manifest-owned config inputs. If the shared sanitizer cannot be changed in this PR, filter or reject non-matching Zalo IDs in the Zalo resolver and document why that local boundary is temporary.
PRA-5	Resolve/justify	security	nemoclaw-blueprint/policies/presets/zalo.yaml:18	Narrow the rules to the concrete long-polling and send/message paths used by `@openclaw/zalo`, or add an explicit policy comment and test evidence explaining why Zalo Bot API paths are unstable and cannot be safely constrained.
PRA-6	Resolve/justify	docs	docs/manage-sandboxes/messaging-channels.mdx:5	Update the messaging channel docs in this PR to include Zalo in supported-channel descriptions, the OpenClaw-only caveat, token and optional settings table, scripted setup exports, `channels add zalo` examples, optional settings list, policy preset references, and frontmatter metadata.
PRA-7	Resolve/justify	tests	src/lib/messaging/channels/zalo/manifest.ts:129	Add or identify targeted local runtime/integration validation for the Zalo build and runtime path. Do not rely on external E2E status alone as the only proof.

🚨 Required before merge

Address these before merging unless a maintainer explicitly overrides the advisor with rationale.

PRA-3 Required — Zalo-specific assertions still grow aggregate test hotspots

• Location: src/lib/messaging/channels/manifests.test.ts:666
• Category: architecture
• Problem: The PR keeps detailed Zalo-only behavior checks in already-large all-channel tests. `src/lib/messaging/channels/manifests.test.ts` grows by 54 lines to 867 lines, and `src/lib/messaging/compiler/manifest-compiler.test.ts` grows by 54 lines to 1460 lines. The aggregate tests now cover Zalo flat render shape, no `accounts` nesting, credential placeholder, package install, health hook, group policy, allowlist behavior, and compiled output.
• Impact: These files are active overlap points for multiple open messaging-channel PRs. Keeping channel-local behavior in aggregate tests increases merge conflicts and makes Zalo regressions harder to distinguish from registry/order failures.
• Required action: Shrink the aggregate tests to registration/order and shared cross-channel invariants. Move Zalo flat `channels.zalo` render, absence of `accounts`, pinned `npm:@openclaw/zalo@{{openclaw.version}}`, provider placeholder, hook registration, group policy, allowlist rendering, and compiled output assertions into focused Zalo test files.
• Expected follow-up: Fix before merge or get explicit maintainer override.
• Verification: Read the Zalo block beginning `declares Zalo as an OpenClaw-only flat-render channel` in `src/lib/messaging/channels/manifests.test.ts` and the Zalo assertions in the OpenClaw aggregate compiler test in `src/lib/messaging/compiler/manifest-compiler.test.ts`; after the fix, those aggregate files should retain only registry/order and shared invariant checks.
• Missing regression test: Add or move focused Zalo tests that prove flat `channels.zalo` render, no `accounts` nesting, pinned plugin install spec, provider placeholder, health hook registration, group policy behavior, allowlist rendering, and compiled output shape without growing the aggregate hotspots.
• Done when: The required change is committed and verification passes: Read the Zalo block beginning `declares Zalo as an OpenClaw-only flat-render channel` in `src/lib/messaging/channels/manifests.test.ts` and the Zalo assertions in the OpenClaw aggregate compiler test in `src/lib/messaging/compiler/manifest-compiler.test.ts`; after the fix, those aggregate files should retain only registry/order and shared invariant checks.
• Evidence: Synthetic drift reports `manifests.test.ts` +54 lines and `manifest-compiler.test.ts` +54 lines. The diff adds a Zalo manifest behavior block at `manifests.test.ts:666` and Zalo render/build/health assertions to the deterministic OpenClaw compiler test.

Review findings by urgency: 1 required fix, 6 items to resolve/justify, 0 in-scope improvements

⚠️ Resolve or justify before merge

Investigate these in the current review; either fix them, explain why they are not applicable, or document the accepted risk.

PRA-1 Resolve/justify — Source-of-truth review needed: ZALO_ALLOWED_IDS persisted config and render path

• Location: not file-specific
• Category: architecture
• Problem: The advisor marked localized patch analysis as missing.
• Impact: A localized workaround can preserve or hide an invalid state when the source boundary is unclear.
• Recommended action: Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
• Expected follow-up: Resolve in this PR or explain why the risk is acceptable.
• Verification: Inspect the localized patch and source-of-truth review fields for a concrete invalid state, source boundary, source-fix constraint, regression test, and removal condition.
• Missing regression test: Missing; add sanitize/hydrate rejection tests for malformed `ZALO_ALLOWED_IDS` and a resolver/compiler test proving malformed stored IDs do not render `allowFrom` or `dmPolicy`.
• Done when: The risk is fixed or explicitly justified in the PR. Verification: Inspect the localized patch and source-of-truth review fields for a concrete invalid state, source boundary, source-fix constraint, regression test, and removal condition.
• Evidence: `manifestConfigInputs` records only `envKey` and `validValues`, while the Zalo resolver only deduplicates parsed IDs.

PRA-2 Resolve/justify — Source-of-truth review needed: Zalo Bot API policy path scope

• Location: not file-specific
• Category: architecture
• Problem: The advisor marked localized patch analysis as needs_followup.
• Impact: A localized workaround can preserve or hide an invalid state when the source boundary is unclear.
• Recommended action: Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
• Expected follow-up: Resolve in this PR or explain why the risk is acceptable.
• Verification: Inspect the localized patch and source-of-truth review fields for a concrete invalid state, source boundary, source-fix constraint, regression test, and removal condition.
• Missing regression test: Missing; add a policy-shape test that asserts narrowed paths or asserts a documented intentionally broad path set.
• Done when: The risk is fixed or explicitly justified in the PR. Verification: Inspect the localized patch and source-of-truth review fields for a concrete invalid state, source boundary, source-fix constraint, regression test, and removal condition.
• Evidence: `zalo.yaml` contains `GET /**` and `POST /**`; tests only add Zalo to the preset name list.

PRA-4 Resolve/justify — Persisted Zalo allowlists can bypass the manifest ID format check

• Location: src/lib/messaging-channel-config.ts:13
• Category: security
• Problem: `ZALO_ALLOWED_IDS` declares `formatPattern: "^[A-Za-z0-9]+(,[A-Za-z0-9]+)*$"`, and direct prompt/compiler input validation can enforce it. The persisted channel config path only records `envKey` and `validValues`, so `normalizeMessagingChannelConfigValue()` does not enforce manifest `formatPattern`. The Zalo resolver then deduplicates `allowedIds(context, "zalo")` without revalidating each ID before rendering `allowFrom` and deriving `dmPolicy`.
• Impact: A stale or tampered persisted `ZALO_ALLOWED_IDS` can become authorization-sensitive OpenClaw bridge config despite violating the manifest contract. Depending on plugin behavior, malformed IDs may weaken allowlist behavior, cause unexpected access decisions, or break the bridge after rebuild.
• Recommended action: Fix the source boundary by carrying manifest `formatPattern` into `normalizeMessagingChannelConfigValue()` for manifest-owned config inputs. If the shared sanitizer cannot be changed in this PR, filter or reject non-matching Zalo IDs in the Zalo resolver and document why that local boundary is temporary.
• Expected follow-up: Resolve in this PR or explain why the risk is acceptable.
• Verification: Compare `manifestConfigInputs` and `normalizeMessagingChannelConfigValue()` in `src/lib/messaging-channel-config.ts` with `allowedIds.formatPattern` in `src/lib/messaging/channels/zalo/manifest.ts` and `zaloAllowedUsers()` in `src/lib/messaging/channels/zalo/template-resolver.ts`.
• Missing regression test: Add a `messaging-channel-config` test proving malformed `ZALO_ALLOWED_IDS` values are rejected during sanitize/hydrate, plus a Zalo resolver or compiler negative test proving malformed stored IDs do not render `allowFrom` or set `dmPolicy`.
• Done when: The risk is fixed or explicitly justified in the PR. Verification: Compare `manifestConfigInputs` and `normalizeMessagingChannelConfigValue()` in `src/lib/messaging-channel-config.ts` with `allowedIds.formatPattern` in `src/lib/messaging/channels/zalo/manifest.ts` and `zaloAllowedUsers()` in `src/lib/messaging/channels/zalo/template-resolver.ts`.
• Evidence: `manifestConfigInputs` maps config inputs to `{ envKey, validValues }`; `validValuesByKey` is the only validation map. `ZALO_ALLOWED_IDS` has a format pattern in the manifest, but `zaloAllowedUsers()` only calls `allowedIds(context, "zalo")` and `Set` deduplication.

PRA-5 Resolve/justify — Zalo policy grants GET and POST to every Bot API path

• Location: nemoclaw-blueprint/policies/presets/zalo.yaml:18
• Category: security
• Problem: The new Zalo preset allows both `GET /**` and `POST /**` for `bot-api.zaloplatforms.com`. The comment identifies long-polling and sending messages, but the policy does not constrain the bridge to concrete Bot API paths or explain why path narrowing is impossible.
• Impact: If the bridge or token is compromised, the sandbox receives broader egress than necessary to the Zalo Bot API. This weakens least-privilege network policy and makes future policy drift harder to detect.
• Recommended action: Narrow the rules to the concrete long-polling and send/message paths used by `@openclaw/zalo`, or add an explicit policy comment and test evidence explaining why Zalo Bot API paths are unstable and cannot be safely constrained.
• Expected follow-up: Resolve in this PR or explain why the risk is acceptable.
• Verification: Read the `rules` block under `bot-api.zaloplatforms.com` in `nemoclaw-blueprint/policies/presets/zalo.yaml` and check whether any test in `test/policies.test.ts` asserts the Zalo path scope.
• Missing regression test: Add a policy-shape test that either asserts narrowed Zalo paths and methods, or asserts the intentionally broad wildcard with a documented rationale so future reviewers can distinguish deliberate scope from accidental expansion.
• Done when: The risk is fixed or explicitly justified in the PR. Verification: Read the `rules` block under `bot-api.zaloplatforms.com` in `nemoclaw-blueprint/policies/presets/zalo.yaml` and check whether any test in `test/policies.test.ts` asserts the Zalo path scope.
• Evidence: The diff adds `- allow: { method: GET, path: "/**" }` and `- allow: { method: POST, path: "/**" }`; `test/policies.test.ts` only adds Zalo to the preset name list and does not validate the Zalo endpoint shape.

PRA-6 Resolve/justify — User-facing messaging docs still omit Zalo

• Location: docs/manage-sandboxes/messaging-channels.mdx:5
• Category: docs
• Problem: The PR exposes Zalo through OpenClaw supported platforms, channel lists, onboarding/add-channel planning, policy presets, and provider cleanup, but the user-facing messaging guide still lists only Telegram, Discord, Slack, WeChat, and WhatsApp in frontmatter, intro text, requirements, examples, optional settings, and policy-preset guidance.
• Impact: Operators can discover Zalo through CLI behavior without documentation for token format, OpenClaw-only support, `ZALO_ALLOWED_IDS`, `ZALO_GROUP_POLICY`, policy preset selection, or `channels add` usage. This raises setup error rates and obscures the new credential and network-policy requirements.
• Recommended action: Update the messaging channel docs in this PR to include Zalo in supported-channel descriptions, the OpenClaw-only caveat, token and optional settings table, scripted setup exports, `channels add zalo` examples, optional settings list, policy preset references, and frontmatter metadata.
• Expected follow-up: Resolve in this PR or explain why the risk is acceptable.
• Verification: Search `docs/manage-sandboxes/messaging-channels.mdx` for `Zalo` or `ZALO_`; currently the file contains no Zalo-specific user guidance despite the new channel being registered.
• Missing regression test: Docs changes do not need a unit regression test; the existing documentation build or frontmatter checks should cover syntax once Zalo content is added.
• Done when: The risk is fixed or explicitly justified in the PR. Verification: Search `docs/manage-sandboxes/messaging-channels.mdx` for `Zalo` or `ZALO_`; currently the file contains no Zalo-specific user guidance despite the new channel being registered.
• Evidence: The repository file `docs/manage-sandboxes/messaging-channels.mdx` still says `Telegram, Discord, Slack, WeChat, and WhatsApp` and its channel requirements table has no Zalo row.

PRA-7 Resolve/justify — Runtime/build validation is still needed for the new Zalo sandbox path

• Location: src/lib/messaging/channels/zalo/manifest.ts:129
• Category: tests
• Problem: The static tests cover registry metadata, compiler output, package spec, and resolver behavior, but this PR adds a build-time plugin install (`npm:@openclaw/zalo@{{openclaw.version}}`), OpenClaw config rendering, network policy, and bridge health-check path without targeted runtime or integration validation in the diff.
• Impact: A static plan can look correct while the image build fails to install the plugin, the plugin rejects the generated `openclaw.json`, the policy blocks required egress, or the bridge health hook never validates a working Zalo runtime.
• Recommended action: Add or identify targeted local runtime/integration validation for the Zalo build and runtime path. Do not rely on external E2E status alone as the only proof.
• Expected follow-up: Resolve in this PR or explain why the risk is acceptable.
• Verification: Review the changed tests listed in the static inventory: they assert static manifest/compiler behavior but do not exercise an actual Zalo plugin install, generated OpenClaw config acceptance, policy egress, or bridge startup/health behavior.
• Missing regression test: Add a behavior-specific runtime validation that builds or dry-runs the Zalo-enabled OpenClaw image path, verifies the generated flat `channels.zalo` config is accepted by the installed `@openclaw/zalo` version, and exercises the bridge health-check/policy path with fake or controlled credentials.
• Done when: The risk is fixed or explicitly justified in the PR. Verification: Review the changed tests listed in the static inventory: they assert static manifest/compiler behavior but do not exercise an actual Zalo plugin install, generated OpenClaw config acceptance, policy egress, or bridge startup/health behavior.
• Evidence: Synthetic test depth reports `runtime_validation_recommended` for `agents/openclaw/manifest.yaml`, `zalo.yaml`, Zalo built-ins, hooks, manifest, and resolver. The diff contains only static Vitest-style assertions for the new channel.

💡 In-scope improvements

These are lower-risk, not throwaway. Prefer fixing them in this PR when they are local to changed code; defer only with rationale or a linked follow-up.

• None.

Simplification opportunities: 1 possible cut

These are safe simplification checks only. Do not remove validation, security controls, data-loss prevention, or required tests.

• PRA-3 shrink (src/lib/messaging/channels/manifests.test.ts:666): Detailed Zalo-only assertions from `src/lib/messaging/channels/manifests.test.ts` and `src/lib/messaging/compiler/manifest-compiler.test.ts`.
  • Replacement: Focused Zalo manifest/compiler tests under `src/lib/messaging/channels/zalo/` or another Zalo-local test file, with aggregate tests limited to ordering and shared invariants.
  • Safety boundary: Do not remove trust-boundary assertions for credential placeholders, package pinning, flat render shape, policy intent, or health hook registration; only move them to lower-conflict focused coverage.

Test follow-ups to resolve or justify

If these cover changed behavior, prefer adding them in this PR; otherwise state why existing coverage is enough or link the follow-up.

• PRA-T1 Runtime validation — Reject malformed persisted `ZALO_ALLOWED_IDS` during `sanitizeMessagingChannelConfig()` and `hydrateMessagingChannelConfig()`.. The PR changes runtime/sandbox infrastructure paths for a new externally connected messaging bridge: agent platform metadata, network policy, plugin install spec, OpenClaw config render, template resolver, hooks, and bridge health scheduling. Static tests are broad but do not prove the actual Zalo build/runtime path.
• PRA-T2 Runtime validation — Do not render `allowFrom` or set `dmPolicy` when stored Zalo allowed IDs fail the manifest alphanumeric comma-list format.. The PR changes runtime/sandbox infrastructure paths for a new externally connected messaging bridge: agent platform metadata, network policy, plugin install spec, OpenClaw config render, template resolver, hooks, and bridge health scheduling. Static tests are broad but do not prove the actual Zalo build/runtime path.
• PRA-T3 Runtime validation — Do not serialize a raw `ZALO_BOT_TOKEN` from env or token-paste hooks into the compiled Zalo plan or rendered OpenClaw config.. The PR changes runtime/sandbox infrastructure paths for a new externally connected messaging bridge: agent platform metadata, network policy, plugin install spec, OpenClaw config render, template resolver, hooks, and bridge health scheduling. Static tests are broad but do not prove the actual Zalo build/runtime path.
• PRA-T4 Runtime validation — Assert the Zalo policy preset uses narrowed Bot API paths, or assert the intentionally broad wildcard with an explicit rationale.. The PR changes runtime/sandbox infrastructure paths for a new externally connected messaging bridge: agent platform metadata, network policy, plugin install spec, OpenClaw config render, template resolver, hooks, and bridge health scheduling. Static tests are broad but do not prove the actual Zalo build/runtime path.
• PRA-T5 Runtime validation — Validate a Zalo-enabled OpenClaw build/runtime path: install the pinned `@openclaw/zalo` package, render flat `channels.zalo`, and exercise the bridge health-check/policy path with controlled credentials or a documented local harness.. The PR changes runtime/sandbox infrastructure paths for a new externally connected messaging bridge: agent platform metadata, network policy, plugin install spec, OpenClaw config render, template resolver, hooks, and bridge health scheduling. Static tests are broad but do not prove the actual Zalo build/runtime path.
• PRA-T6 Runtime/build validation is still needed for the new Zalo sandbox path — Add or identify targeted local runtime/integration validation for the Zalo build and runtime path. Do not rely on external E2E status alone as the only proof.
• PRA-T7 Acceptance clause — each manifest compiles into a stable `SandboxMessagingPlan` — add test evidence or identify existing coverage. `src/lib/messaging/compiler/manifest-compiler.test.ts` adds Zalo to the deterministic OpenClaw plan and asserts channel order, credential binding, policy entry, render entries, build step, health check, and flat Zalo render. The coverage is currently in large aggregate hotspots rather than focused Zalo tests.
• PRA-T8 Acceptance clause — policy plans match current channel policy behavior — add test evidence or identify existing coverage. The manifest references the `zalo` policy preset, the compiler test expects a Zalo policy entry, and `test/channels-add-preset.test.ts` includes Zalo in apply-before-rebuild coverage. The actual Zalo policy path scope is broad and lacks a shape/rationale test.

Since last review details

Current findings, using the urgency labels above:

PRA-1 Resolve/justify — Source-of-truth review needed: ZALO_ALLOWED_IDS persisted config and render path

• Location: not file-specific
• Category: architecture
• Problem: The advisor marked localized patch analysis as missing.
• Impact: A localized workaround can preserve or hide an invalid state when the source boundary is unclear.
• Recommended action: Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
• Expected follow-up: Resolve in this PR or explain why the risk is acceptable.
• Verification: Inspect the localized patch and source-of-truth review fields for a concrete invalid state, source boundary, source-fix constraint, regression test, and removal condition.
• Missing regression test: Missing; add sanitize/hydrate rejection tests for malformed `ZALO_ALLOWED_IDS` and a resolver/compiler test proving malformed stored IDs do not render `allowFrom` or `dmPolicy`.
• Done when: The risk is fixed or explicitly justified in the PR. Verification: Inspect the localized patch and source-of-truth review fields for a concrete invalid state, source boundary, source-fix constraint, regression test, and removal condition.
• Evidence: `manifestConfigInputs` records only `envKey` and `validValues`, while the Zalo resolver only deduplicates parsed IDs.

PRA-2 Resolve/justify — Source-of-truth review needed: Zalo Bot API policy path scope

• Location: not file-specific
• Category: architecture
• Problem: The advisor marked localized patch analysis as needs_followup.
• Impact: A localized workaround can preserve or hide an invalid state when the source boundary is unclear.
• Recommended action: Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
• Expected follow-up: Resolve in this PR or explain why the risk is acceptable.
• Verification: Inspect the localized patch and source-of-truth review fields for a concrete invalid state, source boundary, source-fix constraint, regression test, and removal condition.
• Missing regression test: Missing; add a policy-shape test that asserts narrowed paths or asserts a documented intentionally broad path set.
• Done when: The risk is fixed or explicitly justified in the PR. Verification: Inspect the localized patch and source-of-truth review fields for a concrete invalid state, source boundary, source-fix constraint, regression test, and removal condition.
• Evidence: `zalo.yaml` contains `GET /**` and `POST /**`; tests only add Zalo to the preset name list.

PRA-3 Required — Zalo-specific assertions still grow aggregate test hotspots

• Location: src/lib/messaging/channels/manifests.test.ts:666
• Category: architecture
• Problem: The PR keeps detailed Zalo-only behavior checks in already-large all-channel tests. `src/lib/messaging/channels/manifests.test.ts` grows by 54 lines to 867 lines, and `src/lib/messaging/compiler/manifest-compiler.test.ts` grows by 54 lines to 1460 lines. The aggregate tests now cover Zalo flat render shape, no `accounts` nesting, credential placeholder, package install, health hook, group policy, allowlist behavior, and compiled output.
• Impact: These files are active overlap points for multiple open messaging-channel PRs. Keeping channel-local behavior in aggregate tests increases merge conflicts and makes Zalo regressions harder to distinguish from registry/order failures.
• Required action: Shrink the aggregate tests to registration/order and shared cross-channel invariants. Move Zalo flat `channels.zalo` render, absence of `accounts`, pinned `npm:@openclaw/zalo@{{openclaw.version}}`, provider placeholder, hook registration, group policy, allowlist rendering, and compiled output assertions into focused Zalo test files.
• Expected follow-up: Fix before merge or get explicit maintainer override.
• Verification: Read the Zalo block beginning `declares Zalo as an OpenClaw-only flat-render channel` in `src/lib/messaging/channels/manifests.test.ts` and the Zalo assertions in the OpenClaw aggregate compiler test in `src/lib/messaging/compiler/manifest-compiler.test.ts`; after the fix, those aggregate files should retain only registry/order and shared invariant checks.
• Missing regression test: Add or move focused Zalo tests that prove flat `channels.zalo` render, no `accounts` nesting, pinned plugin install spec, provider placeholder, health hook registration, group policy behavior, allowlist rendering, and compiled output shape without growing the aggregate hotspots.
• Done when: The required change is committed and verification passes: Read the Zalo block beginning `declares Zalo as an OpenClaw-only flat-render channel` in `src/lib/messaging/channels/manifests.test.ts` and the Zalo assertions in the OpenClaw aggregate compiler test in `src/lib/messaging/compiler/manifest-compiler.test.ts`; after the fix, those aggregate files should retain only registry/order and shared invariant checks.
• Evidence: Synthetic drift reports `manifests.test.ts` +54 lines and `manifest-compiler.test.ts` +54 lines. The diff adds a Zalo manifest behavior block at `manifests.test.ts:666` and Zalo render/build/health assertions to the deterministic OpenClaw compiler test.

PRA-4 Resolve/justify — Persisted Zalo allowlists can bypass the manifest ID format check

• Location: src/lib/messaging-channel-config.ts:13
• Category: security
• Problem: `ZALO_ALLOWED_IDS` declares `formatPattern: "^[A-Za-z0-9]+(,[A-Za-z0-9]+)*$"`, and direct prompt/compiler input validation can enforce it. The persisted channel config path only records `envKey` and `validValues`, so `normalizeMessagingChannelConfigValue()` does not enforce manifest `formatPattern`. The Zalo resolver then deduplicates `allowedIds(context, "zalo")` without revalidating each ID before rendering `allowFrom` and deriving `dmPolicy`.
• Impact: A stale or tampered persisted `ZALO_ALLOWED_IDS` can become authorization-sensitive OpenClaw bridge config despite violating the manifest contract. Depending on plugin behavior, malformed IDs may weaken allowlist behavior, cause unexpected access decisions, or break the bridge after rebuild.
• Recommended action: Fix the source boundary by carrying manifest `formatPattern` into `normalizeMessagingChannelConfigValue()` for manifest-owned config inputs. If the shared sanitizer cannot be changed in this PR, filter or reject non-matching Zalo IDs in the Zalo resolver and document why that local boundary is temporary.
• Expected follow-up: Resolve in this PR or explain why the risk is acceptable.
• Verification: Compare `manifestConfigInputs` and `normalizeMessagingChannelConfigValue()` in `src/lib/messaging-channel-config.ts` with `allowedIds.formatPattern` in `src/lib/messaging/channels/zalo/manifest.ts` and `zaloAllowedUsers()` in `src/lib/messaging/channels/zalo/template-resolver.ts`.
• Missing regression test: Add a `messaging-channel-config` test proving malformed `ZALO_ALLOWED_IDS` values are rejected during sanitize/hydrate, plus a Zalo resolver or compiler negative test proving malformed stored IDs do not render `allowFrom` or set `dmPolicy`.
• Done when: The risk is fixed or explicitly justified in the PR. Verification: Compare `manifestConfigInputs` and `normalizeMessagingChannelConfigValue()` in `src/lib/messaging-channel-config.ts` with `allowedIds.formatPattern` in `src/lib/messaging/channels/zalo/manifest.ts` and `zaloAllowedUsers()` in `src/lib/messaging/channels/zalo/template-resolver.ts`.
• Evidence: `manifestConfigInputs` maps config inputs to `{ envKey, validValues }`; `validValuesByKey` is the only validation map. `ZALO_ALLOWED_IDS` has a format pattern in the manifest, but `zaloAllowedUsers()` only calls `allowedIds(context, "zalo")` and `Set` deduplication.

PRA-5 Resolve/justify — Zalo policy grants GET and POST to every Bot API path

• Location: nemoclaw-blueprint/policies/presets/zalo.yaml:18
• Category: security
• Problem: The new Zalo preset allows both `GET /**` and `POST /**` for `bot-api.zaloplatforms.com`. The comment identifies long-polling and sending messages, but the policy does not constrain the bridge to concrete Bot API paths or explain why path narrowing is impossible.
• Impact: If the bridge or token is compromised, the sandbox receives broader egress than necessary to the Zalo Bot API. This weakens least-privilege network policy and makes future policy drift harder to detect.
• Recommended action: Narrow the rules to the concrete long-polling and send/message paths used by `@openclaw/zalo`, or add an explicit policy comment and test evidence explaining why Zalo Bot API paths are unstable and cannot be safely constrained.
• Expected follow-up: Resolve in this PR or explain why the risk is acceptable.
• Verification: Read the `rules` block under `bot-api.zaloplatforms.com` in `nemoclaw-blueprint/policies/presets/zalo.yaml` and check whether any test in `test/policies.test.ts` asserts the Zalo path scope.
• Missing regression test: Add a policy-shape test that either asserts narrowed Zalo paths and methods, or asserts the intentionally broad wildcard with a documented rationale so future reviewers can distinguish deliberate scope from accidental expansion.
• Done when: The risk is fixed or explicitly justified in the PR. Verification: Read the `rules` block under `bot-api.zaloplatforms.com` in `nemoclaw-blueprint/policies/presets/zalo.yaml` and check whether any test in `test/policies.test.ts` asserts the Zalo path scope.
• Evidence: The diff adds `- allow: { method: GET, path: "/**" }` and `- allow: { method: POST, path: "/**" }`; `test/policies.test.ts` only adds Zalo to the preset name list and does not validate the Zalo endpoint shape.

PRA-6 Resolve/justify — User-facing messaging docs still omit Zalo

• Location: docs/manage-sandboxes/messaging-channels.mdx:5
• Category: docs
• Problem: The PR exposes Zalo through OpenClaw supported platforms, channel lists, onboarding/add-channel planning, policy presets, and provider cleanup, but the user-facing messaging guide still lists only Telegram, Discord, Slack, WeChat, and WhatsApp in frontmatter, intro text, requirements, examples, optional settings, and policy-preset guidance.
• Impact: Operators can discover Zalo through CLI behavior without documentation for token format, OpenClaw-only support, `ZALO_ALLOWED_IDS`, `ZALO_GROUP_POLICY`, policy preset selection, or `channels add` usage. This raises setup error rates and obscures the new credential and network-policy requirements.
• Recommended action: Update the messaging channel docs in this PR to include Zalo in supported-channel descriptions, the OpenClaw-only caveat, token and optional settings table, scripted setup exports, `channels add zalo` examples, optional settings list, policy preset references, and frontmatter metadata.
• Expected follow-up: Resolve in this PR or explain why the risk is acceptable.
• Verification: Search `docs/manage-sandboxes/messaging-channels.mdx` for `Zalo` or `ZALO_`; currently the file contains no Zalo-specific user guidance despite the new channel being registered.
• Missing regression test: Docs changes do not need a unit regression test; the existing documentation build or frontmatter checks should cover syntax once Zalo content is added.
• Done when: The risk is fixed or explicitly justified in the PR. Verification: Search `docs/manage-sandboxes/messaging-channels.mdx` for `Zalo` or `ZALO_`; currently the file contains no Zalo-specific user guidance despite the new channel being registered.
• Evidence: The repository file `docs/manage-sandboxes/messaging-channels.mdx` still says `Telegram, Discord, Slack, WeChat, and WhatsApp` and its channel requirements table has no Zalo row.

PRA-7 Resolve/justify — Runtime/build validation is still needed for the new Zalo sandbox path

• Location: src/lib/messaging/channels/zalo/manifest.ts:129
• Category: tests
• Problem: The static tests cover registry metadata, compiler output, package spec, and resolver behavior, but this PR adds a build-time plugin install (`npm:@openclaw/zalo@{{openclaw.version}}`), OpenClaw config rendering, network policy, and bridge health-check path without targeted runtime or integration validation in the diff.
• Impact: A static plan can look correct while the image build fails to install the plugin, the plugin rejects the generated `openclaw.json`, the policy blocks required egress, or the bridge health hook never validates a working Zalo runtime.
• Recommended action: Add or identify targeted local runtime/integration validation for the Zalo build and runtime path. Do not rely on external E2E status alone as the only proof.
• Expected follow-up: Resolve in this PR or explain why the risk is acceptable.
• Verification: Review the changed tests listed in the static inventory: they assert static manifest/compiler behavior but do not exercise an actual Zalo plugin install, generated OpenClaw config acceptance, policy egress, or bridge startup/health behavior.
• Missing regression test: Add a behavior-specific runtime validation that builds or dry-runs the Zalo-enabled OpenClaw image path, verifies the generated flat `channels.zalo` config is accepted by the installed `@openclaw/zalo` version, and exercises the bridge health-check/policy path with fake or controlled credentials.
• Done when: The risk is fixed or explicitly justified in the PR. Verification: Review the changed tests listed in the static inventory: they assert static manifest/compiler behavior but do not exercise an actual Zalo plugin install, generated OpenClaw config acceptance, policy egress, or bridge startup/health behavior.
• Evidence: Synthetic test depth reports `runtime_validation_recommended` for `agents/openclaw/manifest.yaml`, `zalo.yaml`, Zalo built-ins, hooks, manifest, and resolver. The diff contains only static Vitest-style assertions for the new channel.

Workflow run details

This is an automated, non-binding review; it still expects maintainers and agents to respond to each required or warning item. Treat suggestions as current-PR improvements when they touch changed code; defer only with maintainer rationale or a linked follow-up. A human maintainer must make the final merge decision.

[github-actions]

E2E Advisor Recommendation

Required E2E: messaging-providers-vitest, channels-add-remove-vitest, network-policy-vitest, cloud-onboard-vitest
Optional E2E: channels-stop-start-vitest, openclaw-plugin-runtime-exdev-e2e

Dispatch hint: messaging-providers-vitest,channels-add-remove-vitest,network-policy-vitest,cloud-onboard-vitest

Workflow run

Full advisor summary

E2E Recommendation Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required E2E

• messaging-providers-vitest (medium): Validates the live messaging provider/config/redaction path that this PR changes: built-in channel metadata, credential provider placeholders, OpenClaw config rendering, plugin enablement, and sandbox-visible credential boundaries.
• channels-add-remove-vitest (medium): Exercises the real CLI/OpenShell channel lifecycle path after adding a new built-in channel: channels add, policy preset application before rebuild, registry messaging plan persistence, rebuild, and cleanup.
• network-policy-vitest (medium): Required because the PR adds a new network-policy preset. This live job validates policy-add/list behavior and sandbox egress enforcement through the real OpenShell/NemoClaw boundary.
• cloud-onboard-vitest (medium): The built-in OpenClaw manifest and messaging metadata now include Zalo, which can affect hosted full onboarding defaults, provider preparation, sandbox creation, and runtime readiness. Run the full hosted onboarding smoke to catch end-to-end regressions.

Optional E2E

• channels-stop-start-vitest (medium): Useful adjacent confidence for channel registry/rebuild changes: validates start/stop and policy/registry persistence across OpenClaw/Hermes channel lifecycle operations, though it does not specifically prove Zalo.
• openclaw-plugin-runtime-exdev-e2e (medium): Optional plugin-runtime confidence because the Zalo manifest installs a new pinned OpenClaw plugin package via the openclaw-plugin manager.

New E2E recommendations

• Zalo messaging channel (high): Existing live E2E jobs exercise generic messaging/provider and channel lifecycle paths, but none appears to add Zalo specifically and assert ZALO_BOT_TOKEN provider creation, flat channels.zalo rendering without accounts.default, @openclaw/zalo package installation, Zalo policy preset egress to bot-api.zaloplatforms.com, and Zalo bridge health behavior.
  • Suggested test: zalo-messaging-channel-e2e

Dispatch hint

• Workflow: e2e-vitest-scenarios.yaml
• jobs input: messaging-providers-vitest,channels-add-remove-vitest,network-policy-vitest,cloud-onboard-vitest

[github-actions]

Vitest E2E Scenario Recommendation

Required Vitest E2E scenarios: messaging-providers-vitest
Optional Vitest E2E scenarios: None

Dispatch required Vitest E2E scenarios:

• gh workflow run e2e-vitest-scenarios.yaml --ref <pr-head-ref> --field jobs=messaging-providers-vitest

Workflow run

Full Vitest E2E advisor summary

Vitest E2E Scenario Advisor

Base: origin/main
Head: HEAD
Confidence: medium

Required Vitest E2E scenarios

• messaging-providers-vitest: The PR adds a new built-in OpenClaw messaging channel, its policy preset, hook registration, template resolver, and agent manifest support. The existing messaging-providers Vitest job is the closest wired live coverage for the shared messaging provider/policy/rendering pipeline and should catch regressions in channel registration, provider placeholders, policy application, and OpenClaw runtime channel config. There is no existing live-supported typed Zalo scenario in the trusted registry, so use the wired free-standing messaging job rather than inventing a new scenario ID.
  • Dispatch: gh workflow run e2e-vitest-scenarios.yaml --ref <pr-head-ref> --field jobs=messaging-providers-vitest

Optional Vitest E2E scenarios

• None.

Relevant changed files

• agents/openclaw/manifest.yaml
• nemoclaw-blueprint/policies/presets/zalo.yaml
• src/lib/messaging/channels/built-ins.ts
• src/lib/messaging/channels/template-resolver.ts
• src/lib/messaging/channels/zalo/hooks/index.ts
• src/lib/messaging/channels/zalo/hooks/openclaw-bridge-health.ts
• src/lib/messaging/channels/zalo/manifest.ts
• src/lib/messaging/channels/zalo/template-resolver.ts
• src/lib/messaging/hooks/builtins.ts

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/manage-sandboxes/messaging-channels.mdx`:
- Line 7: Update the description-agent field on line 7 to include Zalo in the
list of supported messaging channels. Currently the field mentions Telegram,
Discord, Slack, WeChat, and WhatsApp. Add Zalo to this list to match the
channels that are actually documented on the page.
- Line 142: The host-side command example in the messaging-channels.mdx file
uses `nemoclaw` but should use `$$nemoclaw` to align with coding guidelines for
shared OpenClaw and Hermes documentation pages. Replace `nemoclaw <sandbox> exec
-- openclaw pairing approve zalo <code>` with `$$nemoclaw <sandbox> exec --
openclaw pairing approve zalo <code>` to ensure consistency across the shared
documentation.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: b44592fa-3db4-4653-bb48-6eee5b83e362

📥 Commits

Reviewing files that changed from the base of the PR and between cf403cf and 798a3af.

📒 Files selected for processing (25)

• agents/openclaw/manifest.yaml
• docs/manage-sandboxes/messaging-channels.mdx
• docs/network-policy/integration-policy-examples.mdx
• docs/reference/commands-nemohermes.mdx
• docs/reference/commands.mdx
• nemoclaw-blueprint/policies/presets/zalo.yaml
• src/lib/agent/defs.test.ts
• src/lib/messaging-channel-config.test.ts
• src/lib/messaging/channels/built-ins.ts
• src/lib/messaging/channels/manifests.test.ts
• src/lib/messaging/channels/metadata.test.ts
• src/lib/messaging/channels/metadata.ts
• src/lib/messaging/channels/template-resolver.ts
• src/lib/messaging/channels/zalo/hooks/index.ts
• src/lib/messaging/channels/zalo/hooks/openclaw-bridge-health.ts
• src/lib/messaging/channels/zalo/manifest.ts
• src/lib/messaging/channels/zalo/template-resolver.ts
• src/lib/messaging/diagnostics.test.ts
• src/lib/messaging/hooks/builtins.ts
• src/lib/messaging/hooks/hook-runner.test.ts
• src/lib/onboard/messaging-prep.test.ts
• src/lib/sandbox/channels.test.ts
• test/channels-add-preset.test.ts
• test/policies.test.ts
• test/sandbox-provider-cleanup.test.ts

[hunglp6d]

PR Review Advisor findings:

• 1 & 2 — Zalo covered in the compiler aggregate test + a per-channel manifests.test.ts case (flat channels.zalo, no accounts, ZALO_BOT_TOKEN placeholder, default groupPolicy, dmPolicy/allowFrom omitted). ✅
• 5 — channels add zalo added to the preset-ordering loop (applies the zalo preset before rebuild). ✅
• 6 — pinned npm:@openclaw/zalo@{{openclaw.version}} install spec asserted in metadata.test.ts. ✅
• 4 — no longer applies: this PR carries no docs changes, so nothing advertises Zalo for Hermes. Zalo channel docs are deferred to a tech writer (separate follow-up).

[hunglp6d]

Thanks @cv .
Advisor pass — addressed:

Fixed:

• PRA-2 / PRA-5b — zaloGroupPolicy now rechecks and falls back to allowlist + resolver test.
• PRA-5a — formatPattern/formatHint added to ZALO_BOT_TOKEN (id:secret) and ZALO_ALLOWED_IDS (alphanumeric).
• PRA-4 / PRA-8 — trust-contract comment by agentPackages.
• PRA-6 / T6 / T8 — allowlist coverage added to the focused Zalo resolver test; kept out of the shared compiler suite for peer-consistency.

Justified (no change):

• PRA-3 / PRA-5c — bot-api.zaloplatforms.com GET/POST /** matches the Discord preset; Telegram only narrows because its paths embed the token. Zalo's path scheme isn't pinned upstream.
• PRA-1 / PRA-9 — existing comment already names the upstream plugin rejection of accounts.default as the constraint; a removal-condition annotation would be rot-prone and no peer channel does it.
• PRA-10 / T7 — every built-in channel shares manifests.test.ts / manifest-compiler.test.ts; extracting only Zalo would create the inconsistency, not remove it.