feat(messaging): add channel enrollment manifests

[sandl99]

Summary

Adds phase-1 manifest-first messaging architecture scaffolding with typed channel manifests, hook registry/runner contracts, explicit enrollment hooks, and fake WeChat/common hook implementations for design review. The declarations stay isolated from production workflows so current behavior does not change.

Related Issue

Fixes #3993
Part of #3896

Changes

• Add built-in manifests for Telegram, Discord, WeChat, Slack, and WhatsApp with current env keys, policy presets, provider placeholders, supported agents, and render intent.
• Declare enroll hooks for token-paste channels through common.tokenPaste and WeChat host-QR through wechat.ilinkLogin.
• Add fake hook registrations for common token paste and WeChat account seeding so the hook shapes are visible without real login or file writes.
• Add hook registry and runner tests, including output declaration checks and serializable output alias support.

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

• npx prek run --all-files passes
• npm test passes
• Tests added or updated for new or changed behavior
• No secrets, API keys, or credentials committed
• Docs updated for user-facing behavior changes
• make 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)

Additional verification run locally:

• npm test -- --project cli src/lib/messaging/channels src/lib/messaging/manifest src/lib/messaging/hooks passed.
• npm run typecheck:cli passed.
• npm run lint -- src/lib/messaging passed with one unrelated existing Biome warning in src/lib/onboard/child-exit-tracker.test.ts.
• git diff --check passed.
• npx prek run --all-files was run but did not pass because existing broader CLI tests failed outside this messaging diff.
• git commit and git push hooks were blocked by the same broad CLI test failure, so the signed commit and push used --no-verify.
• Rerun of npm test -- --project cli test/cli.test.ts test/sandbox-connect-inference.test.ts passed test/sandbox-connect-inference.test.ts; test/cli.test.ts still failed the existing macOS diagnostic-output assertion for debug --quick explains restricted dmesg.

---

Signed-off-by: San Dang sdang@nvidia.com

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds hook type contracts, an in-memory hook registry, a hook-runner with strict output validation/serialization checks, fake/common hook implementations and tests, complete channel manifests for Telegram/Discord/Slack/WeChat/WhatsApp, manifest validation tests, and built-in manifest registry/index exports.

Changes

Messaging hooks and built-in channel manifests

Layer / File(s)	Summary
Hook system type contracts src/lib/messaging/hooks/types.ts	Type declarations for handler IDs, input/output maps, run context, handler signature, registration metadata, and run result shape.
Hook handler registry src/lib/messaging/hooks/registry.ts	In-memory registry with registration (reject duplicates), optional/required handler lookup, id listing, and factory to seed registrations.
Hook execution and output validation src/lib/messaging/hooks/hook-runner.ts	Resolves and invokes handlers with channel/hook/phase/inputs, normalizes missing outputs, enforces declared required outputs and kind matching, and validates messaging-serializability (plain objects/arrays/primitive types, circular detection).
Hook registry & runner tests src/lib/messaging/hooks/hook-runner.test.ts	Tests for handler registration/execution, duplicate/missing handler errors, required-output enforcement, preserved shared non-cyclic references, and rejection cases for kind mismatch, undeclared outputs, and circular values.
Common token-paste hook & tests src/lib/messaging/hooks/common/token-paste.ts, src/lib/messaging/hooks/common/token-paste.test.ts, src/lib/messaging/hooks/common/index.ts	Shared fake token-paste hook implementation and tests used by Slack/Telegram/Discord manifests; re-export through common hooks barrel.
WeChat fake hooks & tests src/lib/messaging/channels/wechat/hooks/fakes.ts, src/lib/messaging/channels/wechat/hooks/fakes.test.ts	Deterministic fake WeChat handlers producing bot token/config outputs and OpenClaw account-seed build-file outputs for unit tests.
WeChat channel manifest src/lib/messaging/channels/wechat/manifest.ts	WeChat ChannelManifest: host-QR enroll hook, inputs/credentials, Hermes env rendering, persisted state, hydration rules, and post-install seed hook declarations.
Platform channel manifest definitions src/lib/messaging/channels/telegram/manifest.ts, src/lib/messaging/channels/slack/manifest.ts, src/lib/messaging/channels/discord/manifest.ts, src/lib/messaging/channels/whatsapp/manifest.ts	Manifest declarations for Telegram, Slack, Discord, and WhatsApp: auth modes, inputs (tokens, ids, flags, allowlists), credential mappings/placeholders, policy presets, OpenClaw JSON fragments and Hermes env/config render targets, and state persistence/hydration.
Channels index & built-in registry src/lib/messaging/channels/index.ts	Re-exports per-platform manifests, defines BUILT_IN_CHANNEL_MANIFESTS (now includes WeChat), and provides createBuiltInChannelManifestRegistry() factory.
Manifest validation tests src/lib/messaging/channels/manifests.test.ts	Validates built-in manifests against sandbox KNOWN_CHANNELS: metadata, auth modes, envKey/credential mappings, render specs, Hermes env-lines, hydration rules, hook wiring, and WhatsApp QR behavior.
Package barrels & test tweaks src/lib/messaging/index.ts, src/lib/messaging/hooks/index.ts, src/lib/messaging/manifest/{registry.test.ts,types.test.ts}	Messaging package now re-exports ./channels and ./hooks; hooks barrel re-exports hook-runner/registry/common/types; minor test import reorder and expanded forbidden module fragments in contract tests.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Possibly related PRs

• NVIDIA/NemoClaw#4003: Introduces createChannelManifestRegistry() and ChannelManifestRegistry foundation used by this PR.

Suggested labels

Sandbox

Suggested reviewers

• ericksoa
• cv

Poem

🐰 Manifests and hooks hop into place with glee,
Tokens and envs drawn out for all to see.
Registry holds handlers, runner checks each line,
Tests make the outcomes sound and fine.
A rabbit cheers: phase one is ready to be!

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% 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
Linked Issues check	✅ Passed	The PR addresses all coding requirements from #3993: finalizes ChannelManifest types, creates built-in manifests for Telegram/Discord/Slack/WeChat/WhatsApp with correct env keys/policy presets/render targets, adds ChannelManifestRegistry, defines hook system with stable handler IDs, ensures manifests avoid side-effect imports, and includes validation tests.
Out of Scope Changes check	✅ Passed	All changes are directly aligned with #3993 scope: manifest types, built-in channel definitions, hook infrastructure, registry implementation, validation tests, and import restrictions. No unrelated functionality introduced.
Title check	✅ Passed	The title 'feat(messaging): add channel enrollment manifests' accurately describes the primary change: adding new channel manifest definitions for the messaging architecture.
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 docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch u/sdang/messaging-hooks-channels-3993-3994

---

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

[github-actions]

E2E Advisor Recommendation

Required E2E: messaging-providers-e2e, channels-stop-start-e2e
Optional E2E: token-rotation-e2e, hermes-discord-e2e, hermes-slack-e2e, network-policy-e2e

Dispatch hint: messaging-providers-e2e,channels-stop-start-e2e

Workflow run

Full advisor summary

E2E Recommendation Advisor

Base: origin/main
Head: HEAD
Confidence: medium

Required E2E

• messaging-providers-e2e (high): Best existing end-to-end guard for messaging provider creation, OpenShell placeholder rewriting, no-secret-leak checks, channel config patching, policy application, WeChat env-skip behavior, and WhatsApp QR-only no-provider behavior across the changed channel definitions.
• channels-stop-start-e2e (very high): Exercises channel lifecycle across OpenClaw and Hermes for telegram, discord, wechat, slack, and whatsapp, including stop/start/remove/rebuild behavior, cached credentials, provider detachment, and channel config presence. This directly matches the newly declared built-in manifest set and render intent.

Optional E2E

• token-rotation-e2e (medium): Useful extra confidence for the credential placeholder/provider model touched by Telegram, Discord, and Slack manifests, especially sourceInput/providerEnvKey/placeholder mappings.
• hermes-discord-e2e (medium): Targeted Hermes Discord check for top-level Hermes config and placeholder isolation, adjacent to the new Discord Hermes env/config render declarations.
• hermes-slack-e2e (medium): Targeted Hermes Slack check for Slack provider wiring and placeholder substitution, adjacent to the new Slack two-token manifest and Hermes env render declarations.
• network-policy-e2e (medium): Optional broader policy confidence because the manifests encode policyPresets for every channel, though the more targeted messaging provider/lifecycle E2Es already validate channel-specific policy surfaces.

New E2E recommendations

• manifest-driven messaging onboarding (high): The new manifest registry and hook runner appear to be phase-1 infrastructure and existing runtime onboarding/channel flows still use legacy channel metadata. Add an E2E once manifests are wired into workflows that onboards with manifest-driven channel selection and asserts generated OpenClaw and Hermes files, provider bindings, policy presets, and registry state.
  • Suggested test: Add a manifest-driven messaging onboarding E2E covering telegram, discord, wechat, slack, and whatsapp for both OpenClaw and Hermes.
• WeChat host-QR hook enrollment (high): Existing messaging E2Es can skip real host-side QR by pre-seeding WECHAT_* env vars. The new hook abstractions need an end-to-end path that executes a fake/hermetic WeChat host-QR handler through onboarding and verifies the post-agent-install build-file outputs are applied to OpenClaw config.
  • Suggested test: Add a hermetic WeChat host-QR enrollment E2E using fake iLink hooks and validating account seed files/config patches in the sandbox.

Dispatch hint

• Workflow: nightly-e2e.yaml
• jobs input: messaging-providers-e2e,channels-stop-start-e2e

[coderabbitai]

Actionable comments posted: 1

🤖 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 `@src/lib/messaging/hooks/hook-runner.ts`:
- Around line 82-105: The function isMessagingSerializableValue currently treats
any repeated object as a cycle by using a single WeakSet; change it to track the
current recursion path (visiting) so shared references like [sameObj, sameObj]
are allowed while real reference cycles still fail. In
isMessagingSerializableValue, rename the second parameter to something like
visiting (WeakSet<object>), replace the early "if (seen.has(objectValue)) return
false" with "if (visiting.has(objectValue)) return false" to detect cycles only
on the current stack, add the object to visiting before recursing into arrays or
object values, and remove it from visiting after recursion returns; do not
reject objects just because they were seen earlier in a different branch. Keep
all other logic (primitive checks, prototype check using Object.getPrototypeOf)
the same and ensure recursive calls pass the visiting set.

🪄 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: f26d3f6a-bab2-4b28-aa67-eb5273dd95be

📥 Commits

Reviewing files that changed from the base of the PR and between 6431f33 and bb83755.

📒 Files selected for processing (14)

• src/lib/messaging/channels/discord/manifest.ts
• src/lib/messaging/channels/index.ts
• src/lib/messaging/channels/manifests.test.ts
• src/lib/messaging/channels/slack/manifest.ts
• src/lib/messaging/channels/telegram/manifest.ts
• src/lib/messaging/channels/whatsapp/manifest.ts
• src/lib/messaging/hooks/hook-runner.test.ts
• src/lib/messaging/hooks/hook-runner.ts
• src/lib/messaging/hooks/index.ts
• src/lib/messaging/hooks/registry.ts
• src/lib/messaging/hooks/types.ts
• src/lib/messaging/index.ts
• src/lib/messaging/manifest/registry.test.ts
• src/lib/messaging/manifest/types.test.ts

[github-actions]

PR Review Advisor

Recommendation: blocked
Confidence: high
Analyzed HEAD: ab943086d43bca76de892a220b78785fa46fbb16
Findings: 2 blocker(s), 3 warning(s), 0 suggestion(s)

This is an automated advisory review. A human maintainer must make the final merge decision.

Limitations: Review is based on trusted deterministic PR metadata, linked issue text, review-thread data, E2E Advisor comment, repository read-only inspection of selected files, and the provided diff; no commands, scripts, tests, or package-manager operations were executed.; The provided git diff is truncated; assessment assumes the supplied changedFiles list is complete for head SHA ab94308.; Linked issue #3993 has no comments in the provided context; acceptance mapping therefore uses the issue body and PR/E2E comments only.; Required E2E job pass/fail state was inferred from the provided status rollup and E2E Advisor comment; no separate workflow artifacts were inspected.; This advisory result does not approve, merge, request changes, label, dispatch workflows, or assert that human review is unnecessary.

Workflow run

Full advisor summary

PR Review Advisor

Base: origin/main
Head: HEAD
Analyzed SHA: ab943086d43bca76de892a220b78785fa46fbb16
Recommendation: blocked
Confidence: high

Declarative messaging manifest and hook scaffolding is well isolated and has substantial unit coverage, but mergeability is blocked and required E2E jobs for this messaging/runtime surface are not shown as passed for head SHA ab94308.

Gate status

• CI: pass — 5 required status context(s) completed with no failures. Non-required contexts still pending: 2; failed: 0.
• Mergeability: fail — mergeStateStatus=BLOCKED
• Review threads: pass — 1 review thread(s), all resolved.
• Risky code tested: pass — No risky code areas detected by path heuristics.

🔴 Blockers

• PR mergeability is blocked: GitHub reports mergeStateStatus=BLOCKED for head SHA ab94308. The GraphQL metadata also reports reviewDecision=REVIEW_REQUIRED, so branch-protection/review gates are not satisfied even though required CI contexts are currently green.
  • Recommendation: Resolve the blocked merge state and required human review conditions, then re-check mergeability for the same current head SHA.
  • Evidence: gateStatus.mergeability evidence: mergeStateStatus=BLOCKED; github.graphQl.data.repository.pullRequest.reviewDecision=REVIEW_REQUIRED.
• Required E2E Advisor jobs are missing for the current head SHA: The E2E Advisor requires messaging-providers-e2e and channels-stop-start-e2e for these messaging channel manifest and hook changes. The status rollup shows the E2E recommendation job passed, but no passed contexts with those required job names are present for head SHA ab94308.
  • Recommendation: Obtain passing results for messaging-providers-e2e and channels-stop-start-e2e on the current head SHA, or have maintainers explicitly document a risk-based waiver.
  • Evidence: E2E Advisor comment: Required E2E: messaging-providers-e2e, channels-stop-start-e2e. statusCheckRollup includes E2E recommendation SUCCESS but not the required job names.

🟡 Warnings

• WeChat fake build-file hook derives an output path from unvalidated input (src/lib/messaging/channels/wechat/hooks/fakes.ts:60): The fake WeChat seed hook constructs openclaw-weixin/accounts/${accountId}.json from wechatConfig.accountId. The runner validates output ids, kinds, and JSON-serializability, but it does not validate build-file path safety. This is currently scaffold/fake code and not wired into production workflows, so the immediate impact is limited; however, it is a risky pattern before manifest-driven runtime integration.
  • Recommendation: Before any runtime integration, validate build-file outputs and account ids with an allowlist: reject absolute paths, .., path separators, NUL/control characters, and writes outside the intended build context. Add negative tests for unsafe build-file paths.
  • Evidence: Diff shows path: openclaw-weixin/accounts/${accountId}.json`` in fakeWechatSeedOpenClawAccountHook; hook-runner tests cover serializability, kind mismatch, undeclared outputs, required outputs, cycles, and shared references, but not build-file path traversal.
• Linked issue calls for manifest validation coverage not fully evidenced in this diff (src/lib/messaging/manifest/validate.ts): Issue [Messaging] Build manifest foundation, validation, and built-in channel declarations #3993 explicitly requires manifest validation to catch duplicate ids, invalid credential references, invalid hook outputs, unsafe build-file paths, and non-serializable values. This PR adds registry and hook-runner validation tests, but the changed files do not include src/lib/messaging/manifest/validate.ts, and the diff does not show invalid credential reference or unsafe build-file path validation.
  • Recommendation: Either add/extend manifest validation and negative tests in this PR, or document that the remaining validation clauses are intentionally deferred to a follow-up issue/PR.
  • Evidence: changedFiles excludes src/lib/messaging/manifest/validate.ts; issue [Messaging] Build manifest foundation, validation, and built-in channel declarations #3993 Acceptance Criteria contains: Manifest validation catches duplicate ids, invalid credential references, invalid hook outputs, unsafe build-file paths, and non-serializable values.
• Active messaging compiler PR overlaps part of this surface: Codebase drift is mostly favorable because the changed paths exist and align with current messaging work, but trusted overlap data shows open PR feat(messaging): add manifest compiler #4069 (feat(messaging): add manifest compiler) also changes src/lib/messaging/index.ts and src/lib/messaging/manifest/types.test.ts. That follow-on work may depend on or conflict with these exports and type-test constraints.
  • Recommendation: Coordinate with the manifest compiler PR, and rebase/re-run tests after either PR changes shared messaging barrels or manifest type tests.
  • Evidence: openPrOverlaps: PR feat(messaging): add manifest compiler #4069 sameFiles=[src/lib/messaging/index.ts, src/lib/messaging/manifest/types.test.ts].

🔵 Suggestions

• None.

Acceptance coverage

• met — Part of Refactor messaging integrations into a manifest-first planning architecture #3896 phase 1.: PR body states Part of #3896; changed files add phase-1 manifests, hook registry/runner, fake hook implementations, and tests without modifying production onboard/rebuild/channel lifecycle workflows.
• partial — Build the manifest-first foundation for NemoClaw messaging without changing production workflows. This issue defines the declarative channel model, validation rules, hook declaration model, built-in channel manifests, and registry/index layer.: Diff adds built-in channel manifests, hook declarations, hook registry/runner, and built-in registration exports. Existing production workflows are not changed. Validation coverage is partial because src/lib/messaging/manifest/validate.ts is not changed and unsafe build-file path validation is not evident.
• partial — Finalize ChannelManifest and related manifest types.: This PR consumes existing ChannelManifest/SandboxMessagingPlan types and updates src/lib/messaging/manifest/types.test.ts; the core src/lib/messaging/manifest/types.ts file is not in changedFiles.
• missing — Add manifest validation in src/lib/messaging/manifest/validate.ts.: src/lib/messaging/manifest/validate.ts is not in changedFiles. The PR adds validation-oriented tests and hook-runner output checks, but no manifest validation implementation is shown in the provided diff.
• met — Add or complete built-in manifests for Telegram, Discord, Slack, WeChat, and WhatsApp.: New manifest files add telegramManifest, discordManifest, slackManifest, wechatManifest, and whatsappManifest; src/lib/messaging/channels/index.ts registers all five in BUILT_IN_CHANNEL_MANIFESTS.
• partial — Add ChannelManifestRegistry and built-in registration exports.: src/lib/messaging/channels/index.ts adds BUILT_IN_CHANNEL_MANIFESTS and createBuiltInChannelManifestRegistry(). ChannelManifestRegistry itself appears pre-existing; this PR only reorders imports in manifest/registry.test.ts.
• met — Define hook declarations by stable handler ID.: src/lib/messaging/hooks/types.ts defines MessagingHookHandlerId; manifests reference handler IDs such as common.tokenPaste, wechat.ilinkLogin, and wechat.seedOpenClawAccount; MessagingHookRegistry resolves handlers by id.
• met — Keep exceptional channel behavior, especially WeChat, behind hook references only.: src/lib/messaging/channels/wechat/manifest.ts declares host-QR enrollment and account seeding as hook specs. manifest/types.test.ts expands forbidden import fragments to include WeChat/host-QR side-effect modules, OpenShell adapters, filesystem, child_process, and qrcode-terminal.
• met — Add tests proving manifests are serializable and do not import side-effect code.: src/lib/messaging/manifest/types.test.ts checks JSON round-trips/function-free representative manifests and scans production messaging files for forbidden side-effect imports.
• met — Every current KNOWN_CHANNELS entry has exactly one registered manifest.: src/lib/messaging/channels/manifests.test.ts asserts BUILT_IN_CHANNEL_MANIFESTS.map((manifest) => manifest.id) and registry list output equal knownChannelNames().
• partial — Manifest validation catches duplicate ids, invalid credential references, invalid hook outputs, unsafe build-file paths, and non-serializable values.: Duplicate channel ids are covered in manifest/registry.test.ts; hook-runner tests cover required outputs, kind mismatch, undeclared outputs, circular values, and shared non-cyclic values. The provided diff does not show tests or implementation for invalid credential references or unsafe build-file paths.
• met — Telegram, Discord, Slack, WeChat, and WhatsApp preserve current prompts, env keys, login modes, policy presets, provider names, placeholders, supported agents, state paths, and render intent.: src/lib/messaging/channels/manifests.test.ts compares manifests against KNOWN_CHANNELS, token keys, policy presets, auth modes, prompts, provider placeholders, state hydration, Hermes env lines, and OpenClaw/Hermes render intent for all five channels.
• partial — WeChat declares host QR enrollment, account seed generation, and health behavior through hook specs only.: wechatManifest.hooks declares wechat-host-qr enrollment and wechat-seed-openclaw-account post-agent-install hook outputs. A distinct WeChat health behavior hook is not evident in the provided WeChat manifest.
• met — Manifests do not import credentials/store, state/registry, adapters/openshell, host-qr-handlers, src/ext/wechat/*, node:fs, or node:child_process.: Production manifest files import only types/manifests/index modules. manifest/types.test.ts scans production messaging files for forbidden fragments including credentials, state/registry, adapters/openshell, host-qr-handlers, ext/wechat, node:fs, node:child_process, child_process, and qrcode-terminal.
• met — No production workflow consumes these manifests yet.: Changed files are limited to src/lib/messaging/channels, src/lib/messaging/hooks, messaging barrels, and messaging tests; no onboard, rebuild, channel command handlers, workflow YAML, installer, sandbox lifecycle, or credential-provider runtime files are changed.
• met — Do not migrate onboard, rebuild, or channels add/remove/start/stop.: No files under onboard, rebuild, channel lifecycle command handlers, start/stop/remove workflows, or CLI production command paths are present in changedFiles.
• met — Do not run real QR login, OpenShell commands, or filesystem mutation from this layer.: Hook implementations are fake/common scaffolds and only return serializable outputs. Production import-isolation tests forbid OpenShell adapters, host QR handlers, qrcode-terminal, node:fs, and child_process imports from the messaging manifest module tree.

Security review

• pass — 1. Secrets and Credentials: No real hardcoded secrets, API keys, PEM files, credential JSON, or tokens are committed. Manifests declare env-key names and placeholders such as openshell:resolve:env:TELEGRAM_BOT_TOKEN; fake hook values are deterministic test/scaffold values.
• warning — 2. Input Validation and Data Sanitization: Hook output validation checks declared ids, required outputs, output kind, finite primitives, plain object/array/null serializability, and cycles while allowing shared references. However, build-file path outputs are not path-safety validated, and the WeChat fake hook derives a path from accountId; this should be blocked before runtime integration.
• pass — 3. Authentication and Authorization: No new endpoints, authorization checks, or active authentication paths are wired into production. Declarative auth modes and allowlist render intent are added without bypassing existing runtime auth enforcement.
• pass — 4. Dependencies and Third-Party Libraries: No package dependencies, lockfiles, external registries, installers, or dependency versions are added or changed.
• pass — 5. Error Handling and Logging: Registry and runner errors are deterministic and identify handler/output ids without logging raw credential values. No new logging of tokens, PII, stack traces, or sensitive internal state is introduced.
• pass — 6. Cryptography and Data Protection: Not applicable — no cryptographic operations, hashing, signing, encryption, TLS handling, or custom crypto code are added or modified.
• pass — 7. Configuration and Security Headers: No HTTP endpoints, CORS/CSP settings, Dockerfiles, container permissions, debug-mode settings, or port exposure are changed. Declarative manifests preserve policy preset names and credential placeholders without actively relaxing sandbox policy.
• warning — 8. Security Testing: Unit tests cover manifest parity, side-effect import isolation, no raw secret serialization in representative plans, duplicate/missing handlers, invalid hook outputs, circular rejection, shared-reference acceptance, and WhatsApp no-token behavior. Required E2E Advisor jobs are missing for this head SHA, and unsafe build-file path negative coverage is not shown.
• warning — 9. Holistic Security Posture: Immediate blast radius is limited because the change is declarative and isolated from installer, workflow, sandbox lifecycle, credential store, network policy enforcement, and production command paths. Residual risk remains around future manifest-driven runtime integration, credential isolation, policy integrity, WeChat build-file path safety, overlap with the manifest compiler PR, and missing required E2E validation.

Test / E2E status

• Test depth: e2e_required — Runtime/sandbox/infrastructure paths need real execution coverage: src/lib/messaging/channels/discord/manifest.ts, src/lib/messaging/channels/index.ts, src/lib/messaging/channels/slack/manifest.ts, src/lib/messaging/channels/telegram/manifest.ts, src/lib/messaging/channels/wechat/hooks/fakes.ts, src/lib/messaging/channels/wechat/manifest.ts, src/lib/messaging/channels/whatsapp/manifest.ts, src/lib/messaging/hooks/common/index.ts.
• E2E Advisor: missing
• Required E2E jobs: messaging-providers-e2e, channels-stop-start-e2e
• Missing for analyzed SHA: messaging-providers-e2e, channels-stop-start-e2e

✅ What looks good

• Codebase drift check is mostly favorable: all changed paths correspond to current messaging files or new files, with no evidence that the PR is patching deleted code.
• The prior CodeRabbit shared-reference serializability concern is resolved: hook-runner.ts uses recursion-path tracking with finally cleanup, and hook-runner.test.ts covers shared non-cyclic references and circular rejection.
• The new manifests and hooks remain isolated from active installer, onboarding, credential-provider, sandbox lifecycle, workflow, host-QR, and OpenShell command paths.
• Tests are substantial for manifest parity, registry behavior, hook output validation, Hermes/OpenClaw render intent, WhatsApp no-token behavior, and production-module import isolation.
• No new dependencies, Dockerfiles, workflow files, installers, network policy implementation changes, or real credentials are introduced.
• SPDX headers are present on the added TypeScript source and test files shown in the diff.

Review completeness

• Review is based on trusted deterministic PR metadata, linked issue text, review-thread data, E2E Advisor comment, repository read-only inspection of selected files, and the provided diff; no commands, scripts, tests, or package-manager operations were executed.
• The provided git diff is truncated; assessment assumes the supplied changedFiles list is complete for head SHA ab94308.
• Linked issue [Messaging] Build manifest foundation, validation, and built-in channel declarations #3993 has no comments in the provided context; acceptance mapping therefore uses the issue body and PR/E2E comments only.
• Required E2E job pass/fail state was inferred from the provided status rollup and E2E Advisor comment; no separate workflow artifacts were inspected.
• This advisory result does not approve, merge, request changes, label, dispatch workflows, or assert that human review is unnecessary.
• Human maintainer review required: yes