Exclude fenced code blocks from angle-bracket escaping

The new sanitizer only masks inline code (`...`) before running the angle-bracket regex, so fenced blocks are still rewritten. In practice, streamed code like if (x < 10) is transformed to if (x \< 10), which corrupts common code output and adds backslashes users did not generate. Because sanitizeCardKitMarkdown now runs on every streaming update, this will affect normal code responses that contain < inside fenced markdown blocks.

Useful? React with 👍 / 👎.

Preserve mention formatting in reply fallback path

In reply mode, this function now routes through sendMessageFeishu, but it still precomputes mentions using buildMentionedCardContent (<at id=...></at>) and drops the original mentions argument. The post-message path expects text-style mention markup (or mentions so it can build it), so replies with mentions can render raw tags or fail to notify users. This regression only appears when both replyToMessageId and mentions are provided.

Useful? React with 👍 / 👎.

Fenced code blocks unprotected during angle-bracket escaping

Step 3 replaces inline code spans with \0CODE...CODE\0 markers before applying the angle-bracket regex, but it never protects the contents of triple-backtick fenced blocks. Any < inside a fenced block (e.g. a Python comparison if x < y:) will be matched by the regex and escaped to \<. In standard markdown, backslash escaping is disabled inside code blocks, so the rendered output will show the literal backslash — if x \< y: — corrupting the code display.

Minimal reproducer for sanitizeCardKitMarkdown:

```python
if x < 10:
    print(x)

→ the `<` on the comparison line becomes `\<`.

The same `split(/(^```[\s\S]*?^```)/m)` pattern used in step 2 could protect fenced segments in step 3 (only apply the angle-bracket replace to non-fenced parts), or the inline-code placeholder pass could be extended to also wrap fenced blocks.

<details><summary>Prompt To Fix With AI</summary>

`````markdown
This is a comment left during a code review.
Path: extensions/feishu/src/streaming-card.ts
Line: 70-77

Comment:
**Fenced code blocks unprotected during angle-bracket escaping**

Step 3 replaces inline code spans with `\0CODE...CODE\0` markers before applying the angle-bracket regex, but it never protects the contents of triple-backtick fenced blocks. Any `<` inside a fenced block (e.g. a Python comparison `if x < y:`) will be matched by the regex and escaped to `\<`. In standard markdown, backslash escaping is disabled inside code blocks, so the rendered output will show the literal backslash — `if x \< y:` — corrupting the code display.

Minimal reproducer for `sanitizeCardKitMarkdown`:

if x < 10:
    print(x)

→ the `<` on the comparison line becomes `\<`.

The same `split(/(^```[\s\S]*?^```)/m)` pattern used in step 2 could protect fenced segments in step 3 (only apply the angle-bracket replace to non-fenced parts), or the inline-code placeholder pass could be extended to also wrap fenced blocks.

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

Mention format mismatch in reply fallback path

When mentions is non-empty and replyToMessageId is set, the code first formats mentions with buildMentionedCardContent, which produces card-format syntax (<at id=ou_xxx></at> — unquoted id attribute, no display text). It then passes that pre-formatted string to sendMessageFeishu, which wraps it in a post-format md element. Post md expects text-format mentions: <at user_id="ou_xxx">name</at>.

The two formats are incompatible (different attribute names, quoting, and display text), so mentions will silently fail to render in the reply fallback path.

One fix: pass the original text and the mentions array to sendMessageFeishu instead of the pre-formatted cardText:

if (replyToMessageId) {
  return sendMessageFeishu({ cfg, to, text, mentions, replyToMessageId, replyInThread, accountId });
}

This lets sendMessageFeishu apply buildMentionedMessage (text format) on its own.

This is a comment left during a code review.
Path: extensions/feishu/src/send.ts
Line: 700-702

Comment:
**Mention format mismatch in reply fallback path**

When `mentions` is non-empty **and** `replyToMessageId` is set, the code first formats mentions with `buildMentionedCardContent`, which produces card-format syntax (`<at id=ou_xxx></at>` — unquoted `id` attribute, no display text). It then passes that pre-formatted string to `sendMessageFeishu`, which wraps it in a post-format `md` element. Post `md` expects text-format mentions: `<at user_id="ou_xxx">name</at>`.

The two formats are incompatible (different attribute names, quoting, and display text), so mentions will silently fail to render in the reply fallback path.

One fix: pass the original `text` and the `mentions` array to `sendMessageFeishu` instead of the pre-formatted `cardText`:
```typescript
if (replyToMessageId) {
  return sendMessageFeishu({ cfg, to, text, mentions, replyToMessageId, replyInThread, accountId });
}
```
This lets `sendMessageFeishu` apply `buildMentionedMessage` (text format) on its own.

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

Mask inline code before escaping angle brackets

The inline-code protection in sanitizeCardKitMarkdown is ineffective because it wraps each span as "\0CODE" + match + "CODE\0" but leaves the original < characters inside match; the subsequent angle-bracket regex still sees and escapes them. For example, `x < y` is transformed into `x \< y`, which corrupts rendered code in normal streaming responses. This is a user-visible content regression for any inline code containing comparison operators.

Useful? React with 👍 / 👎.

Preserve inline code spans before escaping angle brackets

The inline-code masking step does not actually protect < inside code spans, because it wraps the original match ("\0CODE" + match + "CODE\0") without removing the angle bracket characters before the next regex runs. As a result, content like `x < y` is rewritten to `x \< y`, which is a user-visible regression in normal streamed responses that include inline comparisons.

Useful? React with 👍 / 👎.

Exclude fenced code blocks from angle-bracket escaping

The sanitizer only attempts to shield inline code via /`[^`]*`/g, so fenced blocks are still processed by the angle-bracket escape regex. In practice, a fenced snippet like if (x < 10) is transformed to include \<, corrupting generated code output for streaming responses that contain < inside triple-backtick blocks.

Useful? React with 👍 / 👎.

Remove length cap when escaping bare angle brackets

The sanitizer only escapes unmatched < when the remainder of the line is at most 80 characters because of [^>\n]{0,80}. Any longer single-line chunk (for example, x < ... with a long tail and no closing >) bypasses sanitization entirely, so Card Kit can still interpret it as an unclosed tag and truncate streaming output. Since this function is the commit’s primary mitigation for truncation, the hard 80-character cap makes the fix unreliable for common long LLM lines.

Useful? React with 👍 / 👎.

Ignore escaped backticks when balancing inline spans

Counting inline backticks with segment.match(/`/g) treats escaped literals (for example \`` in Markdown docs) as unmatched code delimiters, so this branch appends an extra trailing backtick to otherwise valid text. In streaming cards, responses that explain Markdown escaping will be mutated (e.g., To type `becomesTo type `followed by an added `` ``), which is user-visible content corruption introduced by the sanitizer.

Useful? React with 👍 / 👎.

Sanitize final close text before merging snapshots

update() now stores sanitized content in state.currentText, but the final close path still merges raw finalText from reply-dispatcher; when sanitization inserted escapes (for example x < 10), mergeStreamingText no longer sees overlap and appends the raw payload, producing duplicated text and reintroducing unsanitized < on the last Card Kit update. This makes the truncation fix unreliable in the exact cases it targets.

Useful? React with 👍 / 👎.

Recognize indented fenced code blocks when balancing

Fence balancing only counts lines that start at column 0 with ``````, so valid indented fences (common inside lists/quotes) are treated as normal text. If such a fence is unclosed, this logic does not append a closing fence and the inline-backtick pass adds only one backtick, leaving markdown unbalanced and still prone to Card Kit truncation for those replies.

Useful? React with 👍 / 👎.

Preserve multi-backtick inline code spans during escaping

Code-span masking uses /`[^`\n]*`/g, which only handles single-backtick delimiters. Markdown spans with multi-backtick delimiters (for example x < y) remain unmasked, so the angle-bracket sanitizer escapes < inside the code sample and visibly corrupts output for that valid markdown form.

Useful? React with 👍 / 👎.