Greptile Summary

This PR has two distinct concerns: (1) a Telegram-specific fix that corrects a regex alternation-precedence bug in wrapTelegramChatNotFoundError and improves the error message for 403 "bot not member / bot blocked" scenarios, and (2) a new maxAnnounceChars feature that lets callers cap the length of sub-agent completion announcements (motivated by Telegram's 4096-char message limit).

What's good

• The regex fix /403.*(bot.*not.*member|bot.*blocked)/i correctly requires 403 before both alternatives, resolving the original bug.
• The improved error message is clear and actionable for both failure modes.
• The maxAnnounceChars parameter is validated and normalized consistently across the call chain.

Issues found

• In subagent-announce.ts, the truncation appends "\n\n[truncated — full output in transcript]" (~41 chars) after slicing to maxAnnounceChars, so the final string is maxAnnounceChars + 41 characters long. When the feature is used specifically to stay within Telegram's 4096-char hard limit, this overflow could still trigger a "message too long" API error. The slice boundary should be maxAnnounceChars - TRUNCATION_MARKER.length.

Confidence Score: 4/5

• Safe to merge after fixing the off-by-marker-length truncation bug in maxAnnounceChars.
• The primary goal of the PR (regex fix + better error message) is correct and well-implemented. The maxAnnounceChars feature is architecturally sound but has one concrete off-by-N bug: the truncation marker is appended outside the character budget, meaning the output can exceed maxAnnounceChars by ~41 chars, undermining the feature's stated purpose for hard platform limits like Telegram's 4096-char cap. A one-line fix resolves it.
• src/agents/subagent-announce.ts — truncation logic in the maxAnnounceChars branch.

This is a comment left during a code review.
Path: src/agents/subagent-announce.ts
Line: 1401-1407

Comment:
**Truncation marker pushes output past `maxAnnounceChars`**

The slice is taken at `maxAnnounceChars` characters and then the marker `"\n\n[truncated — full output in transcript]"` (~41 chars) is appended **after** the slice. This means the final string is `maxAnnounceChars + 41` characters long — exceeding the very limit the feature is meant to enforce. For Telegram's hard 4096-char limit this would still produce a ~4137-char string, which could trigger a "message too long" API error.

The marker length should be subtracted from the slice boundary:

```suggestion
    const TRUNCATION_MARKER = "\n\n[truncated — full output in transcript]";
    const truncatedFindings =
      typeof params.maxAnnounceChars === "number" &&
      params.maxAnnounceChars >= 1 &&
      findings.length > params.maxAnnounceChars
        ? findings.slice(0, params.maxAnnounceChars - TRUNCATION_MARKER.length) +
          TRUNCATION_MARKER
        : findings;
```

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: "fix(telegram): impro..."}

✅ CI 验证通过

• ✅ check 通过
• ✅ test:extensions 通过（271 文件，2464 测试）
• ⚠️ test:channels 有 2 个失败，但是仓库已有问题，非本 PR 引入

建议：可以直接合并