feat: subscribe to bitable record change events and forward to Agent

[comeonzhj]

Adds support for drive.file.bitable_record_changed_v1 events, allowing the plugin to forward Base record changes to a configured Feishu chat as synthetic Agent messages.

Application scenario: By subscribing to multidimensional table record change events for the Agent, the Agent can participate in task dashboards maintained using multidimensional tables.

Changes:

• src/messaging/types.ts: add FeishuBitableRecordChangedEvent, FeishuBitableRecordAction, FeishuBitableFieldValue interfaces
• src/core/config-schema.ts: add bitableNotifications config field (array of { fileToken, chatId, tableIds?, label? })
• src/messaging/inbound/bitable-handler.ts: new handler that matches incoming events against bitableNotifications config, formats record changes into a human-readable text, and dispatches a synthetic MessageContext to the Agent
• src/channel/event-handlers.ts: add handleBitableRecordChangedEvent with deduplication logic
• src/channel/monitor.ts: register drive.file.bitable_record_changed_v1 handler in the WebSocket EventDispatcher
• README.md / README.zh.md: document the new feature and configuration

Note: the Feishu app must have drive.file.bitable_record_changed_v1 added in its event subscriptions (Developer Console → Events & Callbacks) and must call drive.file.subscribe for each target Base file beforehand.

Made-with: Cursor

[HanShaoshuai-k]

PR Review: feat: subscribe to bitable record change events and forward to Agent

Thanks for the contribution! The direction is valuable, but there are a few questions worth discussing around the feature design and user experience.

1. What can the Agent actually do with these notifications?

The current flow is: bitable record change → build a text description → dispatch as a synthetic message to the Agent. However, the text uses raw field_id values (e.g. fldXXXX) and truncated JSON-serialized field values — it's hard for the Agent to extract meaningful information from this.

More importantly, the Agent lacks sufficient context to produce a valuable response — it doesn't know what the field names mean, what the record represents in a business context, or what action to take. If the Agent simply relays the change into a chat, this is essentially a notification forwarder, which could be achieved with Feishu's built-in automation or bitable automations without involving the Agent at all.

I'd suggest clarifying the core value proposition: What advantage does routing through the Agent provide over a plain webhook notification? If the goal is for the Agent to understand changes and take follow-up actions (update related docs, mention stakeholders, trigger workflows), the notification message needs richer semantic context — field names, record titles, etc. — so the Agent can reason about what happened.

2. The event subscription flow is broken for users

Using this feature requires three steps: enable the event in Developer Console → call the drive.file.subscribe API → configure bitableNotifications.

Step two is the gap. The README says "You can do this via the feishu_drive tool in OpenClaw Agent", but feishu_drive_file does not have a subscribe action — users following the documentation will hit a dead end.

Suggestions:

• Add subscribe capability to the drive tool so users can complete the full flow through the Agent
• Or have the plugin auto-subscribe on startup based on bitableNotifications config
• At minimum, fix the README to avoid misleading users

3. No noise control for high-frequency changes

Bulk operations on a Base table (data imports, scripted batch edits) will trigger a flood of events, each producing a full AI dispatch. This wastes tokens and drowns out useful information in the chat.

Consider: time-window batching (merge changes to the same table within N seconds into one notification), or a configurable rate limit.

4. Code: dispatch bypasses the chat queue

All other event types (message, reaction, card action) go through enqueueFeishuChatTask for per-chat serial processing + withTicket for tracing. The bitable handler skips both, which may cause concurrent dispatch conflicts with normal messages in the same chat (streaming card conflicts, message ordering) and makes these events invisible in diagnose tracing. Suggest aligning with the existing pattern.