human written description

I love Clawd(is). So I am adding Clawd(is) to lots of group chats. Problem is, in some of them, you want the bot to always respond (e.g. for you and partner to manage your home), but in other ones, you want the bot to be on their best behaviour and not annoying (e.g. your padel chat, where the bot should only book padel slots for you).

We have requireMention as a setting, but its either globally on or off, so you can't switch the flag on per-chat granularity. Until now! This adds it.

It should also have sensible precedence rules too, so the most specific option (e.g. adding a per chat override) will have precedence over global settings, and that works both for the on or off modes.

Summary

• add per-telegram-group requireMention overrides with _default/global fallback
• wire group activation/status messaging to reflect telegram overrides
• document override precedence and add Telegram bot tests for gating

Details

Config/schema

• add telegram.groups._default + telegram.groups..requireMention in config schema

Telegram gating

• resolve per-group requireMention override before _default/global fallback
• set WasMentioned for group payloads

Auto-reply/status

• compute group activation using telegram overrides when in telegram groups
• surface effective group activation in status output

Docs

• document precedence and config examples in telegram/configuration/groups docs

Tests

• devenv shell -- pnpm vitest run -- src/telegram/bot.test.ts (ran full suite: 641 passed, 2 skipped)

Prompts (step by step)

1. [2026-01-02 19:50:45 UTC] i want to check out the upstream main (from peter's remote)
2. [2026-01-02 19:50:58 UTC] the seipete one
3. [2026-01-02 19:52:02 UTC] yes pull. then see if we have support for requireMention on a per chat bases for clawdis, or not yet?
4. [2026-01-02 19:53:43 UTC] can we port that to telegram?
5. [2026-01-02 19:55:14 UTC] 1. just do it in clawdis config files.
6. explain?
7. explain?
8. [2026-01-02 19:55:57 UTC] recommendation is good. no to regex patterns imo. use the status thing too if you want.
9. [2026-01-02 20:00:48 UTC] i presume we are backwards compatible? what happens if you configure globally and override locallty? do they all intersect correctly? can we add proper tests?
10. [2026-01-02 20:02:51 UTC] can you make sure that this override behaviour is properly documented?
11. [2026-01-02 20:03:42 UTC] ok. you think it's good to go?
12. [2026-01-02 20:04:44 UTC] make a surgical commit on a branch. open a PR to upstream with a descriptive body entitled "AUTOMATED PR DESCRIPTION: BY AGENTS AND FOR AGENTS". also include all the prompts we used, step by step. have a blank section at the top called "human written description" and leave it blank for me to fill in
13. [2026-01-02 20:06:04 UTC] add timestamps to the prompts btw so we can show off how fast we made the feature
14. [2026-01-02 20:06:30 UTC] use cass
15. [2026-01-02 20:12:41 UTC] upstream feedback: groupsDefault is clunky
    i would put that in groups {default}

what do you think?
14. [2026-01-02 20:12:59 UTC] groupsDefault is clunky
i would put that in groups {default}
or not even
we can just put requreMention as a setting in there
15. [2026-01-02 20:13:23 UTC] i dont really understand
16. [2026-01-02 20:19:12 UTC] can you figure out what's most idiomatic and matches the patterns for other agent configs?

// Option C: Inheritance with "_default"
telegram: {
requireMention: true, // top-level = DMs
groups: {
_default: { requireMention: false }, // all groups unless overridden
"123456789": { requireMention: true } // specific group
}
}

Why _default over default:
default is a JS reserved word
_ prefix = "special key" convention
Clear it's metadata, not a group ID

Or even simpler (Option D):
telegram: {
requireMention: true, // DMs
groupRequireMention: false, // all groups
groupOverrides: {
"123456789": { requireMention: true }
}
}
17. [2026-01-02 20:19:39 UTC] I’d still accept the legacy groupsDefault for backward compatibility (deprecate it in docs), but promote _default
going forward.
-> legacy as in we added it or legacy as in its already there?
18. [2026-01-02 20:20:10 UTC] if we just introduced it in this PR its not legacy