deploy.yml --var flags may not be honored by multiapps plugin (PR #438 follow-up) #455

Symptom

PR #438 added --var flags to the cf deploy invocation in .github/workflows/deploy.yml:129-135 to substitute ${github-dispatch-token} (and the existing ${content-api-key} / ${rebuild-api-key} / ${approuter-url} placeholders) at deploy time.

The CI workflow has not run since #438 merged, so the --var syntax has never been exercised against the multiapps plugin in our deploy pipeline.

Today (2026-06-20), during a local DEV deploy, I discovered that cf deploy --var ... is NOT a recognized flag in either multiapps 3.10.0 (default install) or 3.11.1 (latest as of 2026-06-20). cf deploy --help does not list --var; passing it causes the help text to print and the deploy to abort.

Reproduction

$ cf plugins | grep multiapps
multiapps      3.11.1    ...

$ cf deploy mta_archives/some.mtar -e some.mtaext --var foo=bar -f
# prints help text; deploy fails

Why CI may have been silently broken

GitHub Actions hasn't triggered a Build & Deploy workflow run since #438 merged. The first run will likely fail with an "Unable to resolve tutorials-srv#github-dispatch-token" error from the multiapps deploy service (the same error I saw locally).

Possibilities to investigate:

1. Linux multiapps plugin may differ from Windows. Our local environment is Windows; CI runs on ubuntu-latest. Maybe the Linux build accepts --var and the Windows build doesn't.
2. The plugin's --require-secure-parameters flag (visible in cf deploy --help) may be the right substitute — it accepts secure-parameter values via stdin or env vars in a different shape.
3. Pre-build substitution at mbt build time is the standard alternative: pass values via CF_VAR_<name> env vars to mbt build -e dev.mtaext. (I tested this locally; placeholders survived. Worth verifying with the -e flag's full semantics.)
4. A different CF MTA tool entirely (e.g., cf bg-deploy, cf mta) may accept --var where cf deploy doesn't.

Today's workaround

For today's local DEV deploy I:

1. Edited deploy/dev.mtaext to replace ${github-dispatch-token} with empty literal ''.
2. Re-ran mbt build -e ../deploy/dev.mtaext.
3. Ran cf deploy mta_archives/*.mtar -e ../deploy/dev.mtaext -f (no --var).
4. Reverted the dev.mtaext edit.

The deploy succeeded. tutorials-srv is running with GITHUB_DISPATCH_TOKEN="" — the safe failure mode per the spec at docs/superpowers/specs/2026-06-19-github-dispatch-token-mtaext-design.md. Admin-write debounced rebuilds won't fire until this is fixed and a new deploy lands.

Suggested investigation

• Trigger the existing deploy.yml workflow_dispatch on DEV and observe whether the --var flags actually resolve placeholders or cause the same "Unable to resolve" error I saw locally.
• If broken, the fix is either:
  • Switch to mbt build with CF_VAR_<name> env vars (substitution at build time).
  • Switch to --require-secure-parameters if it provides the expected interface.
  • Use a wrapper tool that does pre-substitution (e.g. envsubst over the mtaext before deploy).

Refs

• PR: fix(deploy): persist GITHUB_DISPATCH_TOKEN via mtaext (#435) #438 (added the unverified --var lines)
• Spec: docs/superpowers/specs/2026-06-19-github-dispatch-token-mtaext-design.md
• Memory: feedback_default_off_flags_need_live_smoke — exactly this pattern (PR landed, no live deploy validation)