Update method fails when globalArguments contain cross-model CEL expressions

[stack72]

Description

When a model's globalArguments contain CEL expressions that reference other models (e.g., model.test-ssh-key.resource.state.swamp_hetzner_crud_test_key.attributes.id), the update method fails because it re-evaluates ALL globalArguments fields — including ones irrelevant to the update operation.

Steps to Reproduce

1. Create two models where one references the other via a CEL expression in globalArguments:

# test-server/definition.yaml
globalArguments:
  name: swamp-hetzner-crud-test-srv
  labels:
    env: test
  server_type: cx23
  image: ubuntu-24.04
  location: fsn1
  ssh_keys:
    - ${{ string(model.test-ssh-key.resource.state.swamp_hetzner_crud_test_key.attributes.id) }}

2. Run a workflow that creates both models (this works — the model.*.resource context is available within the workflow run)
3. From a different workflow or CLI, run the update method on the dependent model (e.g., to update labels)

Expected Behavior

The update method should succeed because it only needs to send updatable fields (labels, name) to the API. The ssh_keys field is not updatable and should not need to be re-evaluated.

Actual Behavior

The update fails with:

Invalid expression: No such key: resource

>    1 | string(model["test-ssh-key"].resource.state.swamp_hetzner_crud_test_key.attributes.id)
                                      ^

The model.*.resource context is only available within the workflow run that created the resource. Running the update from a different workflow or the CLI means that context doesn't exist.

Impact

This affects any model that references another model's data in globalArguments. In our Hetzner Cloud CRUD test suite, this prevents updating servers (references ssh-key) and load-balancers (references network) outside the original create workflow.

Independent models (no cross-model references) update fine.

Environment

• Discovered during Hetzner Cloud CRUD test suite development
• Affects @swamp/hetzner-cloud/servers and @swamp/hetzner-cloud/load-balancers models
• Would affect any model type where globalArguments contains cross-model CEL expressions

Summary

This bug affects the expression evaluation service when running model methods that use globalArguments. The root issue is that ALL globalArguments fields are evaluated for every method call, even when only a subset of fields are relevant to the operation. Two potential fix approaches:

1. Have the update method only evaluate fields relevant to the update API call (based on the method's schema)
2. Make the model.*.resource context persistently available by resolving from the data store rather than requiring an in-memory workflow context
3. Allow data.latest() expressions in model definitions (currently rejected by static validation but works at runtime)

[stack72]

Additional Context: data.latest() in model definitions

After further discussion, the core issue is that data.latest() expressions should be allowed in model definition globalArguments but are currently rejected by static validation.

The globalArguments section serves as a factory pattern — the model definition is self-contained and knows how to build itself, so any workflow can call create/update/delete without needing to pass method-specific inputs. This is the intended design.

The problem is that the only CEL pattern that passes static validation in model definitions is model.*.resource.*, which is scoped to the current workflow execution context. This means:

• It works during the workflow that creates the referenced model
• It fails from a different workflow, or from the CLI
• It makes update and delete impossible to call outside the original create workflow

data.latest() is the right expression for this use case because it resolves from persisted data, making it available regardless of execution context. The CLAUDE.md instructions already recommend data.latest() as the preferred pattern over model.*.resource.*, but it can only be used in workflow step inputs — not in model definitions where it's most needed.

Proposed fix: Allow data.latest() as a valid expression root in model definition static validation, alongside model.*, self.*, and env.*.

[stack72]

Implementation Plan

Approach: Skip expressions with unresolvable model resource/file/data references

Extend the existing "skip unresolved" pattern in ExpressionEvaluationService.evaluateDefinition(). Lines 214-229 of expression_evaluation_service.ts already skip expressions containing inputs.* references when those inputs are not provided. We apply the same principle to model.*.resource, model.*.file, and data.*() references when those models have no resource/file data in the context.

Why this is the right fix

The precedent is already there. The codebase already handles this exact class of problem for inputs.* references — if an expression references an input that was not provided, it is skipped rather than crashing. The model.*.resource case is structurally identical: an expression references context data that does not exist yet. Extending the same skip logic to cover resource/file/data references is a natural, consistent extension.

The safety net already exists. The Proxy in method_execution_service.ts (lines 140-157) catches any attempt to use an unresolved expression at runtime. The flow becomes:

1. Expression cannot be resolved → skip it, leave the raw ${{ ... }} text in the definition
2. If the method actually needs that field → Proxy throws a clear error explaining what is missing
3. If the method does not need that field → everything works fine

This is exactly what happens today for unresolved inputs.* — the fix just extends coverage to model.*.resource.

Minimal blast radius. No YAML schema changes, no new CLI flags, no changes to how workflows build context, no changes to ModelResolver.buildContext(). Expressions that resolved before still resolve. The only behavioral change is: expressions that previously crashed now gracefully defer — which is what users expect.

The alternative approaches are worse:

• "Only evaluate fields the method schema needs" — requires the evaluation service to understand method schemas, a layer violation and much more complex
• "Make model.*.resource persistently available" — already happens when dataRepo is provided; the problem is the referenced model has no data at all, so there is nothing to load
• "Allow data.latest() in definitions" — a workaround that pushes complexity to users

Changes

1. src/domain/expressions/expression_evaluation_service.ts — In evaluateDefinition(), after the existing extractInputReferencesFromCel skip check, add a check using extractDependencies() to skip expressions referencing model.*.resource or model.*.file when the model has no resource/file data in the context. Also skip data.*() function calls when the referenced model has no data.

2. src/domain/models/method_execution_service.ts — Broaden the unresolved-expression detection in executeWorkflow() globalArgs validation (lines 222-234) to also detect unresolved model resource/file expressions, so they are stripped from Zod validation but kept in the raw definition for the Proxy guard. Update the Proxy to throw for any remaining unresolved ${{ ... }} expression, not just inputs.* ones.

3. Tests — Unit tests verifying expressions with model.X.resource references are skipped when the model has no resource data. Integration test covering cross-model resource references that are not yet available.

What does NOT change

• No YAML schema changes
• No new CLI flags or user-facing API changes
• No changes to ModelResolver.buildContext() — it already populates resource/file when data exists
• No changes to workflow execution — workflows already work because they populate context progressively
• No breaking changes for users — expressions that worked before still work; expressions that crashed before now gracefully defer

[stack72]

Reproduction Test Files

After swamp repo init, two command/shell models were created:

base-model (never executed — no resource data on disk):

type: command/shell
typeVersion: 2026.02.09.1
id: 9c086498-ebe5-4707-a99a-86874f10240e
name: base-model
version: 1
tags: {}
globalArguments: {}
methods: {}

dependent-model (references base-model resource in globalArguments):

type: command/shell
typeVersion: 2026.02.09.1
id: d35a58e0-06a9-4140-b261-b9e78ef5aa9b
name: dependent-model
version: 1
tags: {}
globalArguments:
  run: echo hello
  workingDir: ${{ model.base-model.resource.state.result.stdout }}
methods:
  execute:
    arguments:
      run: echo hello

Before fix — swamp model method run dependent-model execute --json fails:

Invalid expression: No such key: resource

>    1 | model["base-model"].resource.state.result.stdout
                             ^

After fix — succeeds:

{
  "modelName": "dependent-model",
  "methodName": "execute",
  "data": {
    "attributes": {
      "exitCode": 0,
      "command": "echo hello",
      "stdout": "hello"
    }
  }
}

Fix: #644