task +create/+update/+comment: description text silently disappears in the Feishu client (Markdown-parsed, failed spans are dropped) - the writer can never detect it

[renlong890510-dot]

Environment

• lark-cli 1.0.86, macOS, Feishu (China) tenant
• Commands: task +create / task +update --description / task +comment (also raw tasks.patch)

Symptom

Task description and comment content look like plain-text fields but are rendered as Markdown in the Feishu client. Spans that parse as emphasis/HTML/headings/links are not degraded to plain text — the content inside is dropped entirely, and:

• the API accepts the write (no error),
• reading the task back via OpenAPI returns the original text unchanged,
• only the human viewing the client sees blank lines / missing words.

So the writer has zero feedback on any channel. Real incident: a QA-handoff task written with 15 **bold** spans — the reviewer's client showed five empty section titles and acceptance criteria reduced to a lone -, and the task was bounced back.

Reproduced rules (33 probe cases, description and comments behave identically)

1. Paired ** / __ / ~~ / *** — always swallowed regardless of surroundings. Worst case: an unclosed ** spanning lines eats everything up to the next **, including line breaks.
2. Single * / _ — swallowed only when the closing delimiter is followed by ASCII punctuation/whitespace/EOL (CJK punctuation does not trigger). This bites identifiers: slg_icon_<placeholder> renders as slg<placeholder>.
3. <x> — swallowed only when < is followed by an ASCII letter, / or ! (HTML-tag heuristic).
4. Line-leading # headings — the whole line disappears (not "rendered as heading" — gone).
5. [label] (url) with a space — write succeeds, client shows only label, the parenthesized part vanishes (while the no-space form [label](url) with an invalid URL is at least loudly rejected with 1470400).

Note the inconsistency: IM message text content is not Markdown-parsed at all (verified safe), so users reasonably assume task text is plain too.

Why this matters for lark-cli specifically

This CLI is primarily driven by agents/scripts. An agent writing task descriptions cannot ever discover this failure — write OK, read-back OK, no error code. It only surfaces when a human complains about a blank task.

Ask (any of these would help)

1. Document the behavior prominently in task +create/+update/+comment help/skill docs.
2. Offer an opt-in --escape-markdown (or a lint warning on risky spans) for description/comment writes.
3. Relay upstream to the Task team: failed Markdown spans should degrade to literal text instead of being dropped — silent data loss in a field the API round-trips verbatim is the real bug.

Happy to share the full 33-case probe matrix and repro script.