Add configurable Feishu thread replies

[patrick-fu]

Summary

Add an opt-in Feishu/Lark reply_in_thread setting so operators can keep bot replies and intermediate gateway messages inside Feishu topic replies instead of flooding the main chat.

Why

Feishu only keeps a message in a topic when the reply API is used with reply_in_thread=true. Existing routing already handles messages that originate inside an explicit topic, but @mentions from the main chat and some progress/status paths do not have thread metadata and can remain as top-level chat messages.

Changes

• Add reply_in_thread to FeishuAdapterSettings, sourced from Feishu platform config or FEISHU_REPLY_IN_THREAD.
• When enabled, force reply-style Feishu sends to set reply_in_thread=true.
• Pass the triggering event message id through Feishu progress and status paths when forced threaded replies are enabled.
• Add adapter regression coverage for the configured forced-thread reply path.

Related

• Related issue: feat(feishu): opt-in reply_in_thread for @-mention replies to keep main chat clean #30990
• Related Feishu topic routing issue: [Feishu] Three bugs in topic routing and @mention detection #33568
• Existing completed topic-progress issue: Feishu topic progress messages create new topics instead of staying in the original topic #6969
• Related root_id/thread_id edge case: [Feishu] root_id fallback for thread_id causes all replies to be threaded #20548
• Similar open PRs: [codex] Add Feishu thread reply toggle #33307, feat(feishu): add configurable reply_in_thread option #39600

Validation

• venv/bin/python -m py_compile gateway/run.py plugins/platforms/feishu/adapter.py tests/gateway/test_feishu.py
• venv/bin/python -m unittest tests.gateway.test_feishu.TestAdapterBehavior.test_send_replies_in_thread_when_thread_metadata_present tests.gateway.test_feishu.TestAdapterBehavior.test_send_replies_in_thread_when_config_enabled tests.gateway.test_feishu.TestAdapterBehavior.test_send_uses_metadata_reply_target_for_threaded_feishu_topic
• git diff --check

[alt-glitch]

This was generated by AI during triage.

Duplicate of #33307 — both add a configurable reply_in_thread toggle for Feishu/Lark (same config key + FEISHU_REPLY_IN_THREAD env var, same forced-thread reply mechanism). #33307 is the earlier-open PR. Suggest consolidating onto it.

[teknium1]

Thanks for the focused Feishu routing work and regression coverage.

This automated hermes-sweeper review is closing this under the standing configuration policy:

• PR commit 0bb12c8fc492b90c5a1be4a5053ec6fe00f5bcf8 adds FEISHU_REPLY_IN_THREAD as a user-facing fallback for the non-secret reply_in_thread behavior (plugins/platforms/feishu/adapter.py:1580 in the PR diff).
• The repository rubric reserves .env for credentials and secrets; behavioral settings belong in config.yaml (AGENTS.md:102-105).
• Current main already transports platform-specific YAML through PlatformConfig.extra (gateway/config.py:477) and passes that dictionary into Feishu settings (plugins/platforms/feishu/adapter.py:1444). A focused config.yaml-only re-scope can use that route without adding an environment variable.
• The related [codex] Add Feishu thread reply toggle #33307 received the same policy outcome; related issue feat(feishu): opt-in reply_in_thread for @-mention replies to keep main chat clean #30990 remains open for the underlying behavior discussion.

A config.yaml-only re-scope is welcome for maintainer review.

---

Closed as not-planned per standing maintainer policy (env-var-for-config). This is a design-direction decision, not a code-quality judgment.

---

Closed as not-planned per standing maintainer policy (env-var-for-config). This is a design-direction decision, not a code-quality judgment — see the Contribution Rubric in AGENTS.md for what the project is looking for. If you believe this policy was misapplied to your change, comment here and a maintainer will take a look.