[Fix #1163] Allow inline arrays in for.in property

[ricardozanini]

Summary

• The for.in property now accepts either a runtime expression (string) or an inline array of objects
• This makes the schema more flexible for cases where the collection is known at definition time, without requiring a runtime expression
• Array items are constrained to type: object as proposed in the issue

Changes

• schema/workflow.yaml: Changed for.in from type: string to oneOf accepting a string or an array of objects
• dsl-reference.md: Updated for.in type documentation to string | array
• examples/for-inline-array.yaml: New example demonstrating inline array usage

Test plan

• All 130 existing validation tests pass
• New example validates against the updated schema

Fixes #1163

[Copilot]

Pull request overview

Updates the workflow schema and documentation to let for.in accept either a string expression or an inline, definition-time array—addressing #1163’s request to hardcode collections directly in workflow definitions.

Changes:

• Updated schema/workflow.yaml so for.in accepts string or array (with items: { type: object }).
• Updated dsl-reference.md to reflect the expanded for.in type.
• Added examples/for-inline-array.yaml demonstrating inline array iteration.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
schema/workflow.yaml	Expands for.in from a single string type to a oneOf supporting string or inline array of objects.
dsl-reference.md	Updates the reference table row for for.in to document the new accepted types.
examples/for-inline-array.yaml	Adds a concrete example of using an inline array for for.in.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

[ricardozanini]

Regarding the suggestion to use $ref: '#/$defs/runtimeExpression' instead of plain type: string for the expression branch:

The plain type: string is intentional. The existing for.in field was type: string before this change, and existing CTK tests and examples use shorthand expressions like .pets and .colors (without the ${ } wrapper). These don't match the runtimeExpression pattern ^\s*\$\{.+\}\s*$.

The runtimeExpression ref is only used in schema locations where oneOf disambiguation against other string types (like uriTemplate) requires it. Here, the oneOf already discriminates by type (string vs array), so there's no ambiguity to resolve. Switching to runtimeExpression would break all existing for.in usages in loose evaluation mode.