#391 Pre-flight checks cannot access method arguments (check context omits methodArgs/unresolvedMethodArgs)

Description

Per-method pre-flight checks (modelDef.checks with appliesTo: [method]) cannot access the method's arguments. The check-execution context is built without any method-args field, so a check can only inspect globalArgs and the definition — never the arguments of the method it is gating. Any check that reads method args sees undefined and therefore always fails (or can never validate them).

This makes it impossible to write an argument-validating pre-flight check, even though checks are explicitly per-method via appliesTo.

Root cause (source)

In src/domain/models/method_execution_service.ts, the pre-flight check loop (in executeWorkflow) invokes each check like this:

const checkResult = await check.execute({
  ...context,            // base MethodContext: repoDir, modelType, modelId, dataRepository, ...
  methodName,
  globalArgs: currentDefinition.globalArguments,
  definition: { id, name, version, tags },
});

No resolved or unresolved method arguments are included. Meanwhile:

• The execute context (same file, ~line 330) does attach unresolvedMethodArgs: { ...filteredRawGlobalArgs, ...rawMethodArgs }.
• The method args are also available at check time via currentDefinition.getMethodArguments(methodName) (used a few lines later to build the ExecutionRequest.methodArgs, ~line 640).

So the args exist at the point checks run; they are simply not passed to check.execute(...). (The swamp model validate path in validation_service.ts builds an equivalent args-less check context.)

Steps to reproduce

A model whose check inspects a method argument always fails. Example with @swamp/ssh (its forward-spec-valid check reads ctx.unresolvedMethodArgs.spec):

swamp model method run <ssh-fleet> forward \
  --input 'hosts:json=["host-1"]' \
  --input action=open --input type=L --input spec=19090:localhost:22

Result — the check rejects a perfectly valid spec:

Pre-flight checks failed for "<fleet>" → forward:
  forward-spec-valid:
    - forward action 'open'/'cancel' requires a `spec`

Confirmed the arg is genuinely invisible to the check (not a parsing issue): it fails identically whether spec is supplied via CLI --input, via a workflow step's inputs:, or persisted in the definition's methods.forward.arguments.

Workaround that proves the method itself is fine — skip the check and the tunnel opens correctly:

swamp model method run <fleet> forward --input ... --skip-check forward-spec-valid
# then: ssh -p 19090 root@localhost  -> reaches the host through the -L tunnel

Expected behavior

The pre-flight check context should include the method's arguments (resolved and/or unresolved — mirroring the execute context's unresolvedMethodArgs), so that appliesTo-scoped checks can validate the arguments of the method they gate. Add e.g. methodArgs / unresolvedMethodArgs to the object passed to check.execute(...).

Actual behavior

Checks receive only { ...context, methodName, globalArgs, definition }. Method arguments are unreachable, so argument-validating checks always fail.

Impact

• Extensions cannot validate method arguments in pre-flight checks; validation must be pushed into the Zod arg schema or into execute() (losing the check/skip/label machinery and the pre-flight failure semantics).
• Any extension that does write such a check (e.g. @swamp/ssh forward-spec-valid) silently always-fails for that method until the check is removed or skipped with --skip-check.

Environment

• swamp 20260520.085517.0-sha.a85f376a (swamp update --check reports up to date)
• Root cause read from source at src/domain/models/method_execution_service.ts (pre-flight check loop in executeWorkflow).
• Linux.