feat(osa) send request channel with payload

[St0rmz1]

Summary

Forwards the active chat surface to the server as a new source.channel field on every security checkup request. The server can use this hint to pick a channel appropriate format (for example, collapsible <details> blocks on capable UIs and flat markdown on Telegram or Slack). This PR only adds the client side signal. The server does not yet read the field and silently drops it at zod parse time, so this change ships safely ahead of any server work.

Also removes the plugin side maybeAppendUpdateReminder() footer that was introduced in 0.1.3. That footer was presentation logic in the wrong layer. The equivalent reminder belongs on the server, where it can key off the reported source.pluginVersion and where admins can edit copy or cadence through the content catalog without cutting a plugin release.

What changed

• index.ts
  • registerTool converted to factory form so OpenClawPluginToolContext.messageChannel is reachable. The factory captures the ctx once and closes over it in execute().
  • Slash command handler typed with a minimal PluginCommandContext shape so ctx.channel is read.
  • New normalizeChannel() helper trims and coerces empty values to undefined so the server never sees source.channel: "".
  • Channel threaded through runFlowSafe to runSecurityAdvisorFlow to doCheckup to submitAudit.
  • maybeAppendUpdateReminder() and its constant deleted.
• src/client.ts: added channel?: string to SubmitAuditPayload.source with a comment explaining the backward compatible rollout.
• CHANGELOG.md: Added, Removed entries under Unreleased.

Backward compatibility

The server today uses a plain z.object({...}) for SecurityAdvisorRequestSchema at cloud/apps/web/src/lib/security-advisor/schemas.ts, with no .strict(). Zod's default on an unknown key is to strip it at parse time (no error, no passthrough). Confirmed by reading the schema source, not just behavior. A plugin sending source.channel against the current server receives an identical response to a plugin that omits it.

Test plan

Verified on a real OpenClaw gateway docker container, installed from npm pack tarball, pointed at prod (https://api.kilo.ai).

Local checks:

• bun run typecheck
• bun run format:check
• bun test (49 pass, 0 fail)

End to end on a live gateway, with a temporary debug log line at the top of doCheckup() that printed the resolved channel value. The debug log was removed before the final repack; both the clean and instrumented builds were exercised on the same container.

• Slash command path: typed /security-checkup in the native control UI. Gateway logged security-advisor: doCheckup start channel=webchat. Report returned normally.
• Tool path (LLM via chat): asked the agent use the kilocode_security_advisor tool to run a security checkup. Gateway logged security-advisor: doCheckup start channel=webchat. Report returned normally.
• Factory style registration confirmed working in the real runtime, not just the registry source that I read earlier.
• Prod server accepted source.channel and returned a valid report on both paths.

Notes from the test:

• The native control UI reports itself as webchat, not control-ui. When the server side rendering PR lands, its channel format lookup should key on webchat (plus whatever Telegram, Slack, Discord, and Kilo Chat actually report, which should be confirmed by the same method when each is wired up).
• On small summarizing models (gpt 4.1 nano, for example), a plain request like can you run the security checkup for me sometimes routes to the wrong tool (a cron or job runner that requires gateway pairing). Forcing the tool by name routes correctly. This is an LLM behavior pattern, not a plugin issue, and did not surface any real breakage.

Ship order

• Safe to publish ahead of any server change.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (3 files)

• CHANGELOG.md
• index.ts
• src/client.ts

---

_{Reviewed by gpt-5.4-2026-03-05 · 1,393,735 tokens}