Thanks for building this! We independently wrote a similar implementation before discovering this PR. Since yours is already in-flight, I'd like to contribute our 12 passing unit tests and some review feedback to help this land.

✅ What looks good

• Clean two-layer drill-down (provider → model) matching Telegram/Discord UX
• P2CardActionTriggerResponse for synchronous card updates on navigation — correct approach
• Separate _build_* card builders keep things readable
• Approval vs picker routing is well-isolated with approval_actions set
• Async switch via _submit_on_loop for the heavy on_model_selected callback

📦 Tests we can contribute

We wrote 12 pytest unit tests (all passing ✅) covering:

• Provider card structure and current-provider marking
• Model card: pagination, back/cancel buttons, multi-page navigation
• Sync dispatch: provider→model, page nav, back, cancel, expired state
• Model selection schedules async work + returns processing card

Test file: tests/gateway/test_feishu_model_picker.py

Happy to open a PR against your branch, or you can pull from zycaskevin/hermes-agent:feat/feishu-model-picker (tests in tests/gateway/test_feishu_model_picker.py). Let me know which you prefer!

🔍 Review observations (non-blocking)

1. No cancel button — Telegrams picker has ✗ Cancel alongside Back. Without it, the only way to dismiss is switching models or waiting for expiry. A model_pick_cancel action that shows a "Cancelled" card + cleans up state would improve UX. We used mx for this.

2. Feishu 4-button-per-action limit — The provider list puts ALL buttons in one "action" element (line ~1489). If there are >4 providers, Feishu will reject the card. We split into groups of 4 across multiple action elements. The 4-model-per-page design means model buttons never hit this limit, but provider buttons could.

3. Double notification on switch — _execute_model_switch both updates the existing card AND sends a separate send() message. This means the user sees the card update + a second message "✅ 模型已切换为...". Intentional or leftover from debugging? Telegram just edits the original message.

4. Unrelated qwen3.6-plus entry — The hermes_cli/models.py diff adds a new model entry that looks unrelated to the picker feature. Consider splitting into separate PRs for cleaner review.

5. State key = picker_id vs chat_id — Using mp_{chat_id} as key means stale state is never cleaned up (just accumulates in _model_picker_state dict). Using chat_id directly (like Telegram) means a new /model naturally overwrites old state. Minor, but worth considering.

Again, great work — happy to help push this over the finish line! Let me know how you'd like me to contribute the tests.