Unused import

stringEnum is imported but never referenced anywhere in the file. This will likely trigger an oxlint error (no-unused-vars / no-unused-imports) during the pre-commit hook.

This is a comment left during a code review.
Path: extensions/adaptive-cards/index.ts
Line: 3

Comment:
**Unused import**

`stringEnum` is imported but never referenced anywhere in the file. This will likely trigger an oxlint error (`no-unused-vars` / `no-unused-imports`) during the pre-commit hook.

```suggestion
import type { OpenClawPluginApi } from "openclaw/plugin-sdk";
```

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

Fixed in 38696298. Removed the unused stringEnum import.

filter(Boolean) silently drops the blank-line separator

The empty string "" on line 96 is intended to produce a blank line between the fallback text and the card marker. However, .filter(Boolean) removes all falsy values — including that empty string — so the blank line is never emitted. When fallback is non-empty the output becomes "<fallback>\n<!--adaptive-card-->..." (single newline, no blank line). When fallback is empty (e.g., the card body contains only Image or Input.* elements that generateFallbackText doesn't handle), the output is just the raw <!--adaptive-card--> markers with no human-readable text at all — meaning channels that don't parse markers (Telegram, IRC, Slack) show nothing or raw comment syntax.

A more explicit construction avoids both problems:

This is a comment left during a code review.
Path: extensions/adaptive-cards/index.ts
Line: 95-104

Comment:
**`filter(Boolean)` silently drops the blank-line separator**

The empty string `""` on line 96 is intended to produce a blank line between the fallback text and the card marker. However, `.filter(Boolean)` removes all falsy values — including that empty string — so the blank line is never emitted. When `fallback` is non-empty the output becomes `"<fallback>\n<!--adaptive-card-->..."` (single newline, no blank line). When `fallback` is empty (e.g., the card body contains only `Image` or `Input.*` elements that `generateFallbackText` doesn't handle), the output is just the raw `<!--adaptive-card-->` markers with no human-readable text at all — meaning channels that don't parse markers (Telegram, IRC, Slack) show nothing or raw comment syntax.

A more explicit construction avoids both problems:

```suggestion
      const parts: string[] = [];
      if (fallback) {
        parts.push(fallback, "");
      }
      parts.push(`${CARD_OPEN_TAG}${cardJson}${CARD_CLOSE_TAG}`);
      if (templateData) {
        parts.push(
          `<!--adaptive-card-data-->${JSON.stringify(templateData)}<!--/adaptive-card-data-->`,
        );
      }
      const markedText = parts.join("\n");
```

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

Fixed in 38696298. Replaced filter(Boolean) with explicit parts array construction -- blank-line separator is now preserved between fallback text and markers. Adopted the exact pattern from your suggestion.

ProgressBar is not part of the Adaptive Cards v1.5 specification

The official Adaptive Cards v1.5 schema explorer does not include a ProgressBar element — it was discussed in early preview proposals but was never added to the released specification. Including it in the tool description will cause the LLM to occasionally attempt to use it, producing cards that fail to render (or silently fall back to nothing) on compliant hosts.

The supported body element types for v1.5 are: TextBlock, RichTextBlock, Image, ImageSet, ColumnSet, Container, FactSet, Table, ActionSet, Media, Input.Text, Input.Number, Input.Date, Input.Time, Input.Toggle, Input.ChoiceSet.

This is a comment left during a code review.
Path: extensions/adaptive-cards/index.ts
Line: 35

Comment:
**`ProgressBar` is not part of the Adaptive Cards v1.5 specification**

The official [Adaptive Cards v1.5 schema explorer](https://adaptivecards.io/explorer/) does not include a `ProgressBar` element — it was discussed in early preview proposals but was never added to the released specification. Including it in the tool description will cause the LLM to occasionally attempt to use it, producing cards that fail to render (or silently fall back to nothing) on compliant hosts.

The supported body element types for v1.5 are: `TextBlock`, `RichTextBlock`, `Image`, `ImageSet`, `ColumnSet`, `Container`, `FactSet`, `Table`, `ActionSet`, `Media`, `Input.Text`, `Input.Number`, `Input.Date`, `Input.Time`, `Input.Toggle`, `Input.ChoiceSet`.

```suggestion
      "Common body element types: TextBlock, ColumnSet, FactSet, Image,",
      "Input.Text, Input.ChoiceSet, Input.Toggle.",
```

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

Fixed in 38696298. Removed ProgressBar and updated the tool description to list the actual v1.5 spec elements: TextBlock, RichTextBlock, ColumnSet, Container, FactSet, Image, ImageSet, Table, ActionSet, Input.Text, Input.Number, Input.Date, Input.Time, Input.Toggle, Input.ChoiceSet.

Route Adaptive Card payload through channel card transport

The adaptive_card tool result is emitted as plain text with embedded markers, but no structured card field is passed to channel delivery. In the Teams channel, native card sending is only triggered when ctx.params.card is present (extensions/msteams/src/channel.ts), while plain text goes through sendText; this means invoking this tool in Teams will send marker-wrapped JSON text instead of an actual Adaptive Card attachment.

Useful? React with 👍 / 👎.

Acknowledged. This is intentionally scoped as a follow-up -- the Teams channel integration (detecting markers in msteams/outbound.ts and routing to sendAdaptiveCardMSTeams()) is called out in the PR description under "What's NOT in This PR". This PR adds the gateway-side tool only; the channel routing is a separate PR to keep scope focused per the repo's one-topic-per-PR rule.

Rename /card command to avoid cross-plugin collisions

This plugin registers a /card command, but LINE already registers the same command name (extensions/line/src/card-command.ts), and plugin command registration rejects duplicates (src/plugins/commands.ts, registerPluginCommand). When both plugins are enabled, one handler is dropped based on load order, so either LINE’s existing card workflow or this extension’s test command becomes unavailable.

Useful? React with 👍 / 👎.

Fixed in 323a2e9. Renamed /card to /acard to avoid the collision with LINE extension's /card command.

Extract RichTextBlock fallback from inlines

generateFallbackText handles RichTextBlock by reading el.text, but Adaptive Card RichTextBlock content is carried in inlines, not text. In practice, cards that use rich text lose their meaningful fallback on non-card channels and degrade to the generic default fallback, so users on Telegram/IRC/etc. miss the actual message content.

Useful? React with 👍 / 👎.

Fixed in d82c8a4. RichTextBlock now properly extracts text from inlines array (handles both plain string inlines and TextRun objects with .text property) instead of looking for a non-existent top-level text field.