Content reference in formRequest dictionary leaves literal "$" before variable token

[BsnizND]

Summary

When a content reference is used inside a dictionary passed to formRequest, Cherri leaves a literal $ before the Shortcuts variable token in the compiled plist.

This is surprising for multipart/form uploads because the form field becomes a text token string that starts with $, instead of a clean variable token. For file/image upload fields, that can prevent the receiving server from treating the field as the intended uploaded file value.

Minimal repro

#include 'actions/web'

#define name Test Upload

@fileInput = ShortcutInput
@response = formRequest(
  "https://example.com/upload",
  "POST",
  {
    "file": "${@fileInput}",
    "title": "hello"
  },
  {}
)

Actual compiled plist shape

In the generated WFFormValues dictionary, the file field compiles roughly like this:

{
  "WFKey": { "Value": { "string": "file" } },
  "WFValue": {
    "Value": {
      "string": "$",
      "attachmentsByRange": {
        "{1, 1}": { "VariableName": "fileInput", "Type": "Variable" }
      }
    },
    "WFSerializationType": "WFTextTokenString"
  }
}

The important part is "string": "$".

Expected behavior

I would expect either:

1. The content reference compiles to only the variable token:

"string": "",
"attachmentsByRange": {
  "{0, 1}": { "VariableName": "fileInput", "Type": "Variable" }
}

2. Or Cherri fails loudly / documents that ${...} content references are not supported inside dictionary values passed to actions such as formRequest.

Workaround

Using this inside the form dictionary works for this case:

{
  "file": "{@fileInput}",
  "title": "hello"
}

That compiles the field value as a pure variable token with no literal $ prefix.

Environment

• Cherri version: v2.3.0 release binary for macOS arm64
• Command included --derive-uuids --skip-sign --debug

Thanks for Cherri. It is making generated Shortcuts much easier to maintain; this one just took a little plist inspection to notice.

[BsnizND]

Quick follow-up: this issue is specifically about the compiled plist shape for ${@fileInput} inside a dictionary value, where Cherri leaves a literal $ before the variable token.

In the integration where I noticed it, there was a separate iOS Shortcuts/share-sheet wrinkle too: depending on the shared item, iOS may still choose a form-encoded request rather than a true multipart upload. So this Cherri issue should not be read as "this one behavior alone caused every upload failure." The Cherri-specific surprise remains that ${@fileInput} compiles to $<variable-token> in the dictionary field, while {@fileInput} compiles to the clean variable token.

The workaround I listed still appears valid for Cherri users who need a variable token inside a form dictionary field.