Feature request: add approval instance create/preview commands

Feature request: add approval instance create/preview commands

Summary

Please add first-class CLI support for creating Feishu/Lark approval instances, including previewing the approval flow before submission.

Suggested commands:

lark-cli approval instances preview --data @approval_request.json --as bot
lark-cli approval instances create --data @approval_request.json --as bot

or a higher-level shortcut that can build the request body from an approval definition and user-provided field values.

Current behavior

The approval domain currently supports querying and operating on existing instances/tasks, for example:

• approval instances get
• approval instances cancel
• approval instances cc
• approval instances initiated
• approval tasks query/approve/reject/transfer/...

But it does not expose POST /open-apis/approval/v4/instances/preview or POST /open-apis/approval/v4/instances as a documented CLI command. Users have to fall back to raw API calls:

lark-cli api POST /open-apis/approval/v4/instances/preview --as bot --data @approval_request.json
lark-cli api POST /open-apis/approval/v4/instances --as bot --data @approval_request.json

This is hard for agents and scripts because approval form payloads are non-trivial and widget-specific.

Why this matters

Creating approval instances is a natural part of approval workflow automation. The current CLI can inspect and operate on approval tasks, but cannot initiate a new approval through the approval command surface.

A first-class command could also document and normalize form widget value formats, which are currently difficult to discover from raw API usage alone.

Related edge case

While trying to create a purchase approval instance through raw API calls, I hit a mismatch between preview and create behavior for a form that contains a Base-backed linked classification widget.

In this case:

• The approval definition contains Base-backed radioV2 fields.
• Historical instance details show those fields are grouped under a parent mutableGroup-like widget.
• POST /open-apis/approval/v4/instances/preview accepted a payload shape that represented the grouped values and returned the expected approval chain.
• POST /open-apis/approval/v4/instances rejected the payload.

The create endpoint returned errors in these shapes:

[1395006] validate form error 控件值不合法或者为空。控件= <parent_group_widget_id>

and, when including the parent group widget directly:

[60022] 审批定义中未找到表单控件, 请重新获取定义详情确认该控件是否存在。index= ..., ID= <parent_group_widget_id>.

Several plausible value shapes were rejected by the create endpoint, including text values, { value, text } values, Base record IDs, and { record_id, value, text } values.

This looks similar in shape to #729, where instances/preview accepts a richer widget value shape than instances.

Expected behavior

A first-class create command should ideally:

1. Expose preview and create through the approval command group.
2. Document the supported form widget value formats.
3. Provide clear errors when a widget type is unsupported by the create endpoint.
4. If possible, normalize form values using the approval definition returned by GET /open-apis/approval/v4/approvals/:approval_code.
5. Cover complex widgets such as fieldList, attachmentV2, radioV2, and Base-backed linked/mutable-group widgets, or explicitly document current OpenAPI limitations.

Environment

• CLI version observed locally: 1.0.32
• Platform: macOS
• Commands used: raw lark-cli api calls against /open-apis/approval/v4/instances/preview and /open-apis/approval/v4/instances

Start with the existing approval command group and its instances/tasks commands, then compare their API patterns with the preview and create endpoints named in the issue. Done means preview and create are exposed as documented approval commands, with supported widget value formats and limitations or errors clearly covered, including the listed complex widgets.