This is a comment left during a code review.
Path: extensions/msteams/src/monitor-handler/inbound-media.ts
Line: 57-66

Comment:
**Graph fallback now triggers for all attachment types, including non-downloadable ones**

The condition was narrowed from `onlyHtmlAttachments` (all attachments are `text/html`) to `hasAttachments` (any attachment exists). While this correctly fixes the thread reply scenario (mixed `text/html` + `file.download.info` without `downloadUrl`), it now triggers a Graph API call for *any* message where direct download returns nothing — including messages with Adaptive Cards (`application/vnd.microsoft.card.adaptive`), Hero Cards, or other metadata-only content types that by design never yield downloadable media.

For every such message, `downloadMSTeamsAttachments` legitimately returns `[]` (nothing to download), but now an unnecessary Graph API call is issued, adding latency and consuming Graph quota.

A more targeted fix would limit the fallback to attachment types that are *expected* to have downloadable content but may be missing their URL:

```suggestion
    const shouldFallbackToGraph =
      attachments.length > 0 &&
      attachments.some(
        (att) =>
          String(att.contentType ?? "").startsWith("text/html") ||
          String(att.contentType ?? "").includes("file.download.info"),
      );

    if (shouldFallbackToGraph) {
```

This preserves the existing `text/html` behavior, adds the new `file.download.info`-without-`downloadUrl` case, and avoids spurious Graph calls for card attachment types.

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

---

This is a comment left during a code review.
Path: extensions/msteams/src/inbound.ts
Line: 122-123

Comment:
**Regex escaping omits `<` and `>` — may break if bot name contains those characters**

The escaping function covers regex metacharacters (`.*+?^${}()|[\]`) but does not escape `<` or `>`. While `<` is not a regex metacharacter, `>` appears in the surrounding pattern `<at[^>]*>…</at>`, so a bot name containing `>` would prematurely close the `[^>]*` alternation and potentially cause the regex to match/corrupt unintended content.

Example: if `botMentionName = "Bot >v2"`, the compiled regex becomes  
`<at[^>]*>Bot >v2</at>` where the `>` in `Bot >v2` terminates the `[^>]*` character class.

Bot display names containing `<`/`>` are unusual in Teams, but defensive escaping costs nothing:

```suggestion
  const escaped = botMentionName.replace(/[.*+?^${}()|[\]\\<>]/g, "\\$&");
```

(Note: `<` and `>` are not special in JS regex, so escaping them is harmless and produces the expected literal match.)

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