bug(base): workflow-get loses inline expressions; document unsafe full-definition round trips

Summary

base +workflow-get can return a successful but lossy representation of workflows configured in the native Base editor: inline formula values appear as empty text, branch operands as null, and loop input expressions as empty arrays. This makes static audits misleading and makes GET → edit → full-definition PUT unsafe unless the definition is independently verified.

This is related to #1548 (lookup-filter round-trip loss), but the observed cases below concern workflow inline expressions across multiple step types, not only lookup fields.

Environment and evidence boundary

• Observed with lark-cli 1.0.95 on macOS, user identity, on 2026-09-12.
• Rechecked the corresponding workflow in a freshly opened native Base editor at the time; an expression was present while the export contained empty text.
• Compared base +workflow-get with the raw lark-cli api GET request to the same /open-apis/base/v3/bases/{base_token}/workflows/{workflow_id} endpoint. Their exported steps were equal; using the raw command did not recover the expression.
• No destructive round-trip PUT was performed to test data loss. The write risk below is inferred from the documented full-replacement contract.
• This is a report of the recorded 1.0.95 observation, not a claim of a fresh reproduction on 1.0.96. Current main still advises editing the returned definition and writing it back without this caveat.

Observed shapes

The following fragments preserve the observed JSON shapes. Business names, IDs, formulas and data are intentionally not included.

A field-level formula API returning its expression correctly is a separate capability; it does not establish that workflow-inline expressions are preserved.

Suggested minimal reproduction for maintainers

Use a disposable workflow and non-sensitive sample fields:

1. In the native editor, configure a record-update action with an inline expression, a branch with an inline calculated left operand, and a loop whose input is a calculated list. Save it.

2. Open the saved workflow again and confirm the expressions are still present.

3. Read it with:

   lark-cli base +workflow-get --base-token '<BASE_TOKEN>' --workflow-id '<WORKFLOW_ID>' --as user
   

4. Compare each relevant step with the native editor. Optionally compare the same resource through the raw GET command.

5. Inspect whether missing expressions are represented as legitimate-looking empty values, without a completeness warning.

These are proposed minimal reproduction steps; the original observation was against an existing workflow, not a newly created three-step public fixture.

Expected behavior

Either:

• the read API/CLI preserves the inline expressions and their references sufficiently for a supported round trip; or
• the CLI clearly documents the unsupported/incomplete representation and warns that the export is not a lossless backup or a safe full-replacement input.

An empty exported value alone should not be treated as proof that the native workflow has an empty/dead condition. Conversely, legitimate intentionally empty values should not all be rejected by a blanket validator.

Impact

• Human/agent audits incorrectly diagnose working expressions as empty writes, dead branches or unused dependencies.
• The current help encourages editing the GET response for +workflow-update; that command documents that PUT replaces the full definition and omitting steps clears the steps. Following the guidance without native verification risks losing configuration.

Request

Please clarify whether inline expressions are unsupported by the upstream workflow API or are lost in CLI serialization, and which versions/configurations are affected. If upstream support is required, a CLI help/skill warning and explicit round-trip limitation would still be useful now.

No tenant identifiers, internal workflow exports, credentials or company data are attached.

Start with lark-cli base +workflow-get and the raw lark-cli api GET request described in the reproduction steps, then compare their workflow steps with the native Base editor. Determine whether inline expressions are lost by the upstream API or CLI serialization. Done means expressions are preserved for a supported round trip, or the workflow-get/workflow-update guidance clearly warns about the limitation and full-replacement risk.