fix(feishu): gate group pairing by target bot

[itsddvn]

Summary

• require exact Feishu bot open_id matches before treating a mention as targeting the current bot
• skip group messages that explicitly mention a different target before media, policy, pairing, or agent routing
• guard WebSocket/webhook dispatch by Feishu header.app_id to avoid cross-app channel handling
• add regression coverage for target/non-target mentions, unknown bot identity, app-id mismatch, and already-paired groups

Test plan

• go test ./internal/channels/feishu
• go build ./...
• go build -tags sqliteonly ./...
• git diff --check upstream/dev...HEAD

[clark-cant]

Maintainer Review

Summary: Gates Feishu group pairing by target bot open_id, drops non-target mentions before media/policy/pairing/routing, adds app_id guard on WS/webhook dispatch, and re-checks pairing state before sending pair codes. 8 files, +728/−56.

Risk level: Medium — touches channel routing, pairing flow, and bot identity fail-closed behavior.

Mandatory gates:

• Duplicate/prior implementation: clear — no duplicate PR or issue for this Feishu multi-agent group fix
• Project standards: passed — scoped to internal/channels/feishu/ plus changelog; no UI/API/CLI parity concerns
• Strategic necessity: clear value — multi-agent Lark groups currently have all bots responding to mentions not targeting them
• CI/checks: green (go ✅, web ✅, release-versioning ✅)

Findings:

Positive signals:

• Fail-closed bot identity change is correct and a security improvement: unknown botOpenID no longer treats any mention as bot mention
• Non-target mention skip is correctly placed before media resolution, policy, pairing, and agent routing
• canRecordUnmentionedGroupMessage cleanly separates history-recording eligibility from full policy acceptance
• IsPaired pre-check in sendPairingReply prevents duplicate pairing requests — good defensive programming
• App_id guard in shouldProcessMessageEvent prevents cross-app event injection
• Excellent test coverage: 6 new tests with realistic mock infrastructure covering non-target mentions (requireMention true/false), target mention pairing, already-paired groups, and app_id match/mismatch
• Structured logging is consistent and includes channel/chat/tenant context throughout

Suggestion:

• canRecordUnmentionedGroupMessage duplicates some checkGroupPolicy logic. Minor — the separation of concerns (policy check vs history-recording eligibility) is reasonable and the shared switch structure is clear enough.

Verdict: APPROVE

Posted by github-maintain