fix(check): void action calls declare no variable; unknown call parameters not hidden (#953 items 1, 7)

[ako]

Part of #953: items 1 and 7. Group "e" handles items 2-6.

Item 1: output names on void action calls

Measured on mxbuild 11.13.0 (JTSBootLogboek copy, mxcli exec --no-check, then mxcli docker check):

Construct	mxbuild
two void Java calls $ReturnValueName = … (microflow)	0 errors
two void JS calls $RefreshEntity = … (nanoflow)	0 errors
void call $V1 = …, then declare $V1 String (microflow and nanoflow)	0 errors
void call $V3 = …, then log … $V3	CE0109 Undefined variable 'V3'
void JS call $W = …, then a non-void JS call $W = …	0 errors
nanoflow: non-void call in each if/else branch	CE0111
nanoflow: parameter + declare / declare in loop + after it / declare in each branch	CE0111 each
microflow: declare in an error-handler body + declare after it	CE0111

So the output name on a void call doesn't declare anything: it can't collide with a later variable, and you can't use it either.

What Studio Pro stores (FeedbackModule, Marketplace-authored, bson dump): void JS calls appear as OutputVariableName "Variable"/UseReturnVariable false, "Variable"/true and "ReturnValueName"/true. Exec writes the bare form call javascript action X(…) as ""/false. Dropping $X = from describe would therefore change Studio-authored models on a round trip. Describe keeps printing the stored name. Only the declaration count changes.

Changes:

• voidCodeActions resolves a call's return type from the script (create java/javascript action … returns Void), or with -p from the project, which is opened lazily. If neither knows the action, the call still counts as a declaration. Guessing void there would hide a real CE0111.
  • Gotcha: the Java action reader returns a nil ReturnType for Void, while the JS reader returns VoidType. A mock that only had the typed form passed while the real project failed. Both forms are now covered.
• MDL063 skips void calls, walks error-handler bodies (measured above), and now also runs for nanoflows. This fixes the false negative: the if/else duplicate in jt.mdl is now reported. The message names the document kind.
• The check-time body validator (validateFlowBody) no longer reports duplicate names for microflows and nanoflows. It scoped them per branch and counted void calls, so it was wrong in both directions. MDL063 now owns that check. Rules keep the old check, since MDL063 doesn't run on them.
• Describe's -- WARNING: duplicate output variable … model is invalid no longer fires for void calls.

Item 7: check --references and unknown parameter names

The Java/JS parameter-name check already existed. The repro (r1.mdl) hit it only because of two masking points:

• cmd_check returned before the reference tier whenever a semantic rule reported an error. In the repro, MDL063 was a true positive, since ValidateEmail returns Boolean.
• validateWithContext returned a flow's body errors instead of its reference errors.

Both lists are now reported. The catalog-backed tier still waits for a clean script.

There was also a real gap: call microflow / call nanoflow arguments were never checked against the callee's parameters. Measured CE1613 The selected parameter 'M.F.Bogus' no longer exists for both, including a callee with no parameters. They are now checked against script-created and stored flows. An action or flow known to take no parameters now reports any named argument; previously an empty list meant "unknown".

Note: CE1613 hides every other error in the same mx check run, so each fault was measured separately.

Test plan

• New tests:
  • mdl/executor/validate_void_code_calls_test.go (void/non-void controls, nanoflow flow-wide, String contains not a producer, stored return types incl. nil-for-void, body validator handing duplicates to MDL063 with rule control, describe warning)
  • validate_flow_call_params_test.go (flow-call params with controls, body error not hiding reference errors)
  • cmd/mxcli/check_void_calls_test.go: end to end on a PedApp copy. Stored void JS action pair passes; Boolean control fails with MDL063; the r1 shape reports both MDL063 and has no parameter "email".
• Revert checks: each fix removed, the test fails, fix restored. Void skip in MDL063 (unit + cmd test), nanoflow MDL063 call, nanoflow kind seeding, describe void skip, flow-call param check, body-error/ref-error combination, body-validator hand-off, cmd_check tier gate, Java nil-ReturnType handling.
• Existing tests updated: bugfix_test.go duplicate tests and cmd_microflows_duplicate_output_test.go now assert MDL063 (the single owner). Removed two tests that asserted per-branch scoping for the body validator; mxbuild contradicts that scoping (CE0111 across branches).
• go test ./mdl/executor/ ./mdl/linter/... ./cmd/mxcli/, make build, make lint, make check-conformance, make check-findings, make check-skill-mdl, make sync-skills
• mxbuild evidence on a fresh copy of the JTS app, with NF_Ev_RefreshTwice (two void JS) and MF_Ev_VoidTwice (two void Java plus a declare of the same name):
  • mxcli check -p → Check passed! (it was MDL063 twice)
  • mxcli exec applied both flows
  • mx check → the 4 baseline errors only, 0 added
  • describe microflow MF_VoidTwice no longer prints the "model is invalid" warning
  • The repros: b1n.mdl passes, jt.mdl reports MDL063 (mxbuild CE0111), r1.mdl reports MDL063 plus the CE1613 parameter error, bp2.mdl reports the flow-call params

Follow-ups (not done here)

• Using a void call's output name later is CE0109 in mxbuild; check does not flag it yet.
• Describe's duplicate-output warning still treats exclusive if/else branches as separate scopes. mxbuild does not (CE0111). A test pins that behaviour, so it needs its own change.
• The LSP calls ValidateMicroflow/ValidateNanoflow without a project resolver, so it still flags void calls to stored actions.

🤖 Generated with Claude Code