Heading level always defaults to 1

The code reads level from obj.level, but the Feishu card JSON stores it in obj.property.level (as shown in the fixture). Since obj.level is always undefined, every heading falls back to level 1 and renders as #, regardless of the actual heading depth in the input.

The test fixture encodes this buggy behavior — all expected headings are # even when the source JSON has "level": 2 or "level": 3.

Fix by checking the property object as well, consistent with how getContent already handles property fallbacks:

This is a comment left during a code review.
Path: extensions/feishu/src/card-parser.ts
Line: 91

Comment:
**Heading level always defaults to 1**

The code reads `level` from `obj.level`, but the Feishu card JSON stores it in `obj.property.level` (as shown in the fixture). Since `obj.level` is always undefined, every heading falls back to level `1` and renders as `#`, regardless of the actual heading depth in the input.

The test fixture encodes this buggy behavior — all expected headings are `#` even when the source JSON has `"level": 2` or `"level": 3`.

Fix by checking the `property` object as well, consistent with how `getContent` already handles property fallbacks:

```suggestion
        const level = (obj.level as number) || ((obj.property as Record<string, unknown>)?.level as number) || 1;
```

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

Button text silently dropped when no actions array

The button handler only produces output when an actions array exists. If a button has a text property but no actions, the label is completely lost and an empty string is returned. The btnText variable is computed inside the actions loop, so it's only used when actions are present.

Consider falling back to render button text alone when no actions are available:

This is a comment left during a code review.
Path: extensions/feishu/src/card-parser.ts
Line: 142-162

Comment:
**Button text silently dropped when no `actions` array**

The `button` handler only produces output when an `actions` array exists. If a button has a `text` property but no `actions`, the label is completely lost and an empty string is returned. The `btnText` variable is computed inside the actions loop, so it's only used when actions are present.

Consider falling back to render button text alone when no actions are available:

```suggestion
        }
        // Fallback: render button text without a URL
        const textObj = text as Record<string, unknown> | undefined;
        const textProp = textObj?.property as CardElement | undefined;
        const btnText =
          typeof text === "string"
            ? text
            : (textProp?.content as string) || (textObj?.content as string) || "";
        return btnText;
```

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

Code block language identifier not included

The code_block handler ignores the language field from the card JSON (e.g., "language": "javascript"). The test fixture contains code blocks with language: "bash" and language: "javascript", but the output always renders as bare ``` without any language hint, losing syntax highlighting in markdown renderers.

Include the language identifier in the fenced code block:

This is a comment left during a code review.
Path: extensions/feishu/src/card-parser.ts
Line: 219-235

Comment:
**Code block language identifier not included**

The `code_block` handler ignores the `language` field from the card JSON (e.g., `"language": "javascript"`). The test fixture contains code blocks with `language: "bash"` and `language: "javascript"`, but the output always renders as bare ` ``` ` without any language hint, losing syntax highlighting in markdown renderers.

Include the language identifier in the fenced code block:

```suggestion
          return `\n\`\`\`${(property?.language as string) || ""}\n${text}\n\`\`\`\n`;
```

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

Read heading level from the element property

Feishu heading nodes in raw card payloads carry their level under property.level (the new fixture uses that shape), but this parser reads obj.level, so every heading without a top-level level is rendered as H1. That flattens section hierarchy in quoted card content and degrades the structure the agent receives from multi-level docs/cards.

Useful? React with 👍 / 👎.

Parse top-level card headers before generic fallback

Top-level Feishu card headers are commonly objects like { header: { title: { tag: "plain_text", content: "..." } } }, but this path sends obj.header back into the generic parser, which has no title handling for untagged header objects and emits an [unknown: ...] block instead of the title text. As a result, quoted interactive cards with headers lose their primary heading content.

Useful? React with 👍 / 👎.

Parse object titles in card_header nodes

card_header title fields are often rich-text objects (for example plain_text nodes), but this code coerces obj.title / obj.property.title to a string and then re-parses that value. When the title is an object, the output becomes # [object Object] instead of the real header text, so quoted interactive cards lose their primary heading content.

Useful? React with 👍 / 👎.

Parse top-level header title instead of recursing generically

When a raw card includes a top-level header object like { "header": { "title": { "tag": "plain_text", "content": "..." } } }, this branch recurses into obj.header as an untagged object, which falls through to the default formatter and emits [unknown: ...] instead of the actual title text. In quoted interactive cards that use this common header shape, the primary heading is lost, so the parsed markdown omits key context.

Useful? React with 👍 / 👎.

Handle top-level header.title objects explicitly

When the card root has a header object (for example the shape produced by extensions/feishu/src/streaming-card.ts with header.title.tag = "plain_text"), this line recurses into the untagged header object and falls through to the unknown formatter, yielding [unknown: ...] instead of the actual title text. As a result, quoted interactive cards lose their primary heading context even though the title is present in payload.

Useful? React with 👍 / 👎.

Avoid concatenating block children without separators

For markdown nodes that carry rich children in property.elements, this joins every child with "", so block-level nodes (for example blockquote, which exists in test/fixtures/feishu-card-parser/card-input.json) get glued to adjacent paragraphs (API.Note in the fixture output) instead of being separated as distinct blocks. This degrades readability and loses card structure in quoted content.

Useful? React with 👍 / 👎.

Read table cells using declared column names

This parser indexes each row with idx.toString() instead of the column’s declared key, so any table whose columns[].name values are not "0", "1", etc. will render blank cells even though row data exists. In cards that use semantic column keys, quoted table content loses most of its data.

Useful? React with 👍 / 👎.

Normalize object fields in action_link nodes

The action_link branch assumes url and text are strings, so payloads that provide structured values (for example property.url as { url: "..." } or rich-text text) are interpolated as [object Object] and produce broken markdown links. This causes quoted cards with structured action links to lose readable/clickable link output.

Useful? React with 👍 / 👎.

Normalize object URLs before rendering button links

When a button action carries a structured URL (for example { "url": "https://..." }, which is a shape already handled in the link branch), this code stores the whole object in url and interpolates it directly, producing markdown like [Go]([object Object]) instead of a clickable link. This breaks quoted card output for cards whose button action URL is object-typed rather than a plain string.

Useful? React with 👍 / 👎.

Preserve blank lines when normalizing parsed markdown

The global text.replace(/\n{3,}/g, "\n\n") normalization also runs inside fenced code blocks, so cards containing code with intentional multiple blank lines are silently rewritten (e.g. line1\n\n\nline2 becomes line1\n\nline2). This loses fidelity of quoted interactive card content and can change the meaning/readability of code snippets users are replying to.

Useful? React with 👍 / 👎.

Blockquote prefixes blank lines with > (trailing space)

When an inner element produces content that ends in a newline (e.g., headings return "# text\n\n", code blocks, or hr elements), the .split("\n") produces trailing empty strings that each get > prepended. This results in lines like > (blockquote marker with a trailing space) in the rendered output, which is technically valid CommonMark but clutters the output and may be visually odd in raw markdown views.

Consider filtering empty lines before prefixing, or trimming trailing newlines from inner before splitting:

This is a comment left during a code review.
Path: extensions/feishu/src/card-parser.ts
Line: 143-156

Comment:
**Blockquote prefixes blank lines with `> ` (trailing space)**

When an inner element produces content that ends in a newline (e.g., headings return `"# text\n\n"`, code blocks, or `hr` elements), the `.split("\n")` produces trailing empty strings that each get `> ` prepended. This results in lines like `> ` (blockquote marker with a trailing space) in the rendered output, which is technically valid CommonMark but clutters the output and may be visually odd in raw markdown views.

Consider filtering empty lines before prefixing, or trimming trailing newlines from `inner` before splitting:

```suggestion
      case "blockquote": {
        const elems = getElements(obj);
        if (elems) {
          const inner = elems.map((e) => parseFeishuCardToMarkdown(e, depth + 1)).join("");
          return (
            "\n" +
            inner
              .trimEnd()
              .split("\n")
              .map((line) => `> ${line}`)
              .join("\n") +
            "\n"
          );
        }
        return "";
      }
```

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