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

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.

Start with task +create, task +update --description, task +comment, and raw tasks.patch; reproduce the 33 probe cases and compare write/read-back with Feishu rendering. Determine whether this repository can document the behavior, add lint or escaping, or relay it upstream. Done when the selected mitigation is explicit and reflected in the relevant help or skill documentation.