Validate step input overrides against model schema

[stack72]

Context

PR #240 added "implicit inputs" - the ability for step/CLI inputs to override model definition attributes. Currently, inputs are applied blindly without validation:

for (const [key, value] of Object.entries(inputs)) {
  evaluatedDefinition.setAttribute(key, value);
}

Requirements

1. Fail if input key doesn't exist: If a user provides an input with a key that doesn't exist in the model's inputAttributesSchema, throw an error
2. Fail if type doesn't match: If a user provides a value with a type that doesn't match the expected type in the schema (e.g., providing an integer where a string is expected), throw an error

Proposed Approach

Create an InputOverrideValidationService that validates input overrides against a model's Zod schema. Use existing utilities from schema_path_validator.ts and patterns from method_execution_service.ts.

1. Create InputOverrideValidationService

File: src/domain/inputs/input_override_validation_service.ts

export interface InputOverrideValidationResult {
  valid: boolean;
  errors: InputOverrideError[];
}

export interface InputOverrideError {
  key: string;
  message: string;
  suggestion?: string;
  availableKeys?: string[];
}

export class InputOverrideValidationService {
  validate(
    inputs: Record<string, unknown>,
    schema: z.ZodTypeAny,
  ): InputOverrideValidationResult;
}

Logic:

• Use getObjectKeys() from schema_path_validator.ts to get valid keys from schema
• For each input key, check if it exists in schema keys
• If key doesn't exist, use findClosestKey() for typo suggestions
• For type validation, use getObjectProperty() to get the property schema, then safeParse() to validate the value

2. Update CLI Path

File: src/cli/commands/model_method_run.ts (lines 189-192)

Validate inputs before applying them as overrides. Throw UserError with helpful message listing unknown keys or type mismatches.

3. Update Workflow Path

File: src/domain/workflows/execution_service.ts (lines 270-273)

Same pattern as CLI path - validate step inputs against the model's schema before applying overrides.

4. Add Tests

File: src/domain/inputs/input_override_validation_service_test.ts

Test cases:

• Valid input key with correct type passes
• Invalid input key fails with helpful error message
• Valid key with wrong type fails (e.g., string instead of number)
• Typo suggestions work correctly
• Empty inputs always pass

Files to Modify

1. Create: src/domain/inputs/input_override_validation_service.ts - New validation service
2. Create: src/domain/inputs/input_override_validation_service_test.ts - Tests
3. Modify: src/domain/inputs/mod.ts - Export new service
4. Modify: src/cli/commands/model_method_run.ts - Add validation before overrides
5. Modify: src/domain/workflows/execution_service.ts - Add validation before overrides

Manual Testing

# Test invalid key (should fail)
swamp model method run testEcho run --input '{"invalidKey": "value"}'

# Test type mismatch (should fail)
swamp model method run testEcho run --input '{"message": 123}'

# Test valid override (should succeed)
swamp model method run testEcho run --input '{"message": "override"}'

[stack72]

Type Coercion Clarification

Investigated the concern that "CEL expressions always return strings" - this is incorrect.

Findings

1. CEL preserves types: CelEvaluator.evaluate() returns unknown and directly passes through whatever type cel-js returns. Numbers stay numbers, booleans stay booleans, arrays stay arrays.

2. replaceExpressions preserves types for whole expressions: In expression_parser.ts lines 140-144, when the entire string is a single expression like ${{ inputs.memory }}, the evaluated value is returned directly without string conversion.

3. String conversion only for inline expressions: Only expressions embedded in larger strings (e.g., "Value: ${{ count }}") are converted to strings. Whole expressions preserve their native type.

4. Test evidence: cel_evaluator_test.ts confirms numbers stay numbers, booleans stay booleans.

Conclusion

When a step input like memory: ${{ inputs.memory }} is evaluated:

1. YAML parses the string
2. CEL evaluates and returns the native type (e.g., 1024 as number)
3. replaceExpressions replaces the whole string with the number 1024

No special type coercion handling is needed. Using strict safeParse() is the correct behavior.