feat: add DingTalk channel plugin with OpenClaw connector

[duguwanglong]

• Add dingtalk channel plugin files to .flocks/plugins/channels/dingtalk/ including dingtalk.py, runner.ts and dingtalk-openclaw-connector
• Add channels/dingtalk/ as the source copy alongside runtime plugin
• Pin axios to 1.14.0 in connector package.json for version stability
• Initialize root workspace package.json / package-lock.json

[xiami762]

Overall

The approach is clear: dingtalk.py spawns Node, runner.ts provides a minimal OpenClaw runtime shim, and plugin.ts keeps calling streamFromGateway against a local HTTP proxy that translates to Flocks’ POST /api/session, POST .../message, and GET /api/event. That design is reasonable.

Main risks: global SSE is not filtered by session, integration bypasses the normal channel inbound path, and dependency / docs / version consistency.

---

Must-fix (high priority)

1. /api/event is a global broadcast — filter by sessionID

Flocks’ SSE uses a global EventBroadcaster; every subscriber sees the same stream. In runner.ts, flocksToOpenAIStream consumes message.part.updated / message.updated without checking that properties.part.sessionID (or the equivalent on message.updated) matches the current request’s sessionId.

The server already includes sessionID on those events (e.g. publish_event("message.part.updated", {"part": {..., "sessionID": sessionID}})).

With multiple DingTalk conversations or other clients (Web/TUI) running sessions at once, the proxy can merge another session’s deltas or completion signals into the wrong OpenAI-style SSE response — incorrect behavior and possible cross-session leakage. Filter all handled events by sessionId before yielding or finishing.

2. Python start() never calls on_message

GatewayManager passes on_message = InboundDispatcher.dispatch. DingTalkChannel.start only starts the subprocess and monitors it; it never turns DingTalk traffic into InboundMessage and forwards it to the dispatcher.

So DingTalk does not go through dedup, debounce, channel.inbound hooks, session binding, group policies, etc., like Feishu/WeCom. Either document this explicitly (“by design: direct Session API only, not InboundDispatcher”) or bridge inbound events if parity is required.

3. Doc’d optional config vs actual env / cfg

dingtalk.py documents dmPolicy, allowFrom, separateSessionByConversation, etc. as passed through to plugin.ts, but the subprocess env and the cfg.channels['dingtalk-connector'] object in runner.ts only carry a small subset. Either plumb those options through (e.g. env or JSON blob) or trim the doc so users are not misled.

---

Medium priority

4. First run and lockfiles

The child runs npm run start:runner under dingtalk-openclaw-connector, so npm install must be run first. validate_config does not check node_modules or script availability — failures may be late and opaque.

The PR includes bun.lock but no package-lock.json while the launcher uses npm. For reproducible installs and CI, commit package-lock.json, or standardize on Bun and change dingtalk.py accordingly — avoid npm without a lockfile.

5. Version skew

openclaw.plugin.json says 0.7.4; package.json says 0.7.5. Align them.

6. mark_connected() timing

mark_connected() runs right after Popen, before runner/proxy/DingTalk are actually ready. If accurate status matters, consider a readiness signal (stdout line or local HTTP probe) before marking connected.

7. Repo layout and size

Everything lives under .flocks/plugins/channels/dingtalk/, including a very large plugin.ts. ChannelRegistry loads <cwd>/.flocks/plugins/channels, so the plugin appears when the repo root is the working directory; document behavior when cwd is elsewhere.

Long term, prefer submodule, versioned npm dependency, or a fetch script instead of vendoring a huge file for easier security review and upgrades.

8. Licensing

The subtree has its own MIT LICENSE and upstream repo metadata — ensure compatibility with the main project license and consider a short NOTICE for third-party origin.

---