mcpx: run fails on scripts with @param holes instead of pointing at recipes run #276

Summary

mcpx run <recipe> executes a recipe's @param holes as written and dies with a raw runtime syntax error that names neither the hole nor the command that fills it. This is the run half of dezren39/darwin-nix#367 (fixed there by PR #382), still present in this repo's pkgs/mcpx copy. The greet half of that issue is local to Drew's Mac and is not part of this one.

Evidence (reproduced on main 410275d, 2026-10-18)

Built mcpx from this repo and ran a recipe script (.mcpx/scripts/greet.ts):

// @param name: who to greet
log.info(`hello ${@name}`)

mcpx run greet output:

error: Uncaught (in promise) TypeError: SyntaxError: Expression expected
2 | log.info(`hello ${@name}`)
  |                        ~

• pkgs/mcpx/internal/cli/scripts.go has no hole check: no refuseRecipeHoles / declaresParams anywhere under internal/cli/, and runScript (internal/cli/commands.go) never refuses a recipe before handing it to the runtime.
• pkgs/mcpx/internal/cli/recipe_holes_test.go does not exist in this copy.
• A full diff of this copy against dezren39/nix's post-fix copy shows the difference is exactly the nix PR docs(workflow): C001 trigger-issue draft (PR #381) mixes link bases — one pointer is dead, and the checker strips the fenced draft so it cannot catch it #382 change set: the refuseRecipeHoles block in runScript, the helpers in scripts.go, the unit test file, and the e2e test TestRunOnARecipePointsToRecipesRun.

Why it matters

A recipe's holes are filled only by mcpx recipes run, which substitutes values before anything executes. run executing the file as written guarantees a confusing failure for anyone who reaches for the more obvious command — the error looks like a bug in their script, not a wrong-command mistake.

Acceptance criteria

• mcpx run <recipe> on a script declaring @param holes refuses before the runtime starts, naming the recipe and its holes.
• The refusal points at the filling command: mcpx recipes run <name> hole=<value>... for a recipe on the script path, or mcpx recipes save + recipes run for a path-addressed recipe file off the search path.
• Plain scripts are untouched — including scripts whose body contains a bare @name with no @param declaration — and an unresolvable script name still gets the run's own resolution error.
• Unit tests for the check plus an e2e test that run on a recipe points at recipes run (mirroring dezren39/nix PR docs(workflow): C001 trigger-issue draft (PR #381) mixes link bases — one pointer is dead, and the checker strips the fenced draft so it cannot catch it #382) pass; the raw SyntaxError no longer appears.

Suggested fix

Port dezren39/nix PR #382: refuseRecipeHoles in internal/cli/scripts.go (head-only @param declaration match, recipes.Parse for the placeholder list), called from runScript for the non-inline path, with recipe_holes_test.go and the e2e test ported (issue refs re-pointed to this issue).