Summary

A Feishu group whose only configured override is channels.feishu.groups.<chat_id>.requireMention=false (with no groupAllowFrom) was silently dropped on the inbound path because the schema-default groupPolicy="allowlist" rejects an empty allowlist before the per-group requireMention is ever evaluated. Treat the explicit presence of a group entry under channels.feishu.groups as the operator's allowlist signal so the per-group settings actually take effect.

Root Cause

In extensions/feishu/src/bot.ts, handleFeishuMessage resolves groupConfig from channels.feishu.groups.<chat_id> and then runs isFeishuGroupAllowed({ groupPolicy, allowFrom: groupAllowFrom, ... }) against the top-level groupAllowFrom only. With the validated config defaults (groupPolicy="allowlist", groupAllowFrom=[]), evaluateSenderGroupAccessForPolicy returns allowed:false, reason:"empty_allowlist" and handleFeishuMessage returns before resolveFeishuReplyPolicy (which honors per-group requireMention) ever runs. Result: every group message is dropped, exactly as reported by @Artyomkun in #67687.

Changes

• extensions/feishu/src/bot.ts: in the group admission block, check whether the group is explicitly listed under channels.feishu.groups.<chat_id> (via the already-resolved groupConfig). If yes, treat it as admitted regardless of groupAllowFrom. Existing behaviors are preserved: groupConfig.enabled === false still drops the message, the per-sender effectiveGroupSenderAllowFrom allowlist still applies, and resolveFeishuReplyPolicy still owns mention gating.
• extensions/feishu/src/bot.test.ts: add a regression test that exercises the reporter's exact config shape (only groups."oc-explicit-group".requireMention=false, no top-level groupAllowFrom, default groupPolicy="allowlist") and asserts the inbound text reaches finalizeInboundContext/dispatchReplyFromConfig.

Reproduction (before fix)

With the reporter's config and the prior code, handleFeishuMessage logs feishu[<account>]: group <chat_id> not in groupAllowFrom (groupPolicy=allowlist) and returns. The new test in bot.test.ts failed before this fix (it expected mockFinalizeInboundContext/mockDispatchReplyFromConfig to be called and they were not, because the function returned at the admission gate).

Verification (after fix)

$ pnpm test extensions/feishu/src/bot.test.ts
 Test Files  1 passed (1)
      Tests  55 passed (55)

pnpm tsgo:prod (core + extensions) and pnpm lint:extensions both exit 0. Full extension suite shows 663/666 pass; the 3 failures are in extensions/feishu/src/docx.test.ts (feishu_doc image fetch hardening), reproduce on upstream/main without this change, and are unrelated to the group admission code path.

Test

• Regression test: extensions/feishu/src/bot.test.ts > admits group when chat_id is explicitly configured under groups, even with empty groupAllowFrom (#67687) — verifies the reporter's config shape is admitted.
• Full Feishu bot suite: pnpm test extensions/feishu/src/bot.test.ts — 55/55 pass.
• No change to src/plugin-sdk/group-access.ts (shared by Teams/Mattermost/Zalo/Feishu); fix is intentionally plugin-local to avoid cross-plugin regressions.

Notes

• This follows the conservative direction in clawsweeper's review on [Bug]: Group messages not reaching session - requireMention: false not working (Feishu) #67687 ("treat explicit channels.feishu.groups.<chat_id> entries as admitted groups under groupPolicy: 'allowlist'").
• Backwards compatible: configurations that already worked (top-level groupAllowFrom populated, or groupPolicy="open", or no groups.<chat_id> entry) keep their existing behavior.

Closes #67687