Feature: explicit cross-platform execution modes for script steps (exec/shell/auto)

[e-s-gh]

Summary

Script execution semantics need a clear, cross-platform contract for exec vs shell behavior.

Today, workflows can implicitly depend on shell builtins/expansion on some environments, while others rely on direct executable invocation. This leads to portability confusion and brittle behavior across Windows/macOS/Linux.

Why this is platform-level

This is not specific to one workflow. Any script step can be affected by differences in:

• shell builtins (echo, true, false, etc.)
• argument quoting/escaping
• command-not-found signaling differences (127, 9009, platform stderr text)

Requested feature

Add an explicit script execution mode in workflow schema and executor behavior:

• execution_mode: exec | shell | auto (or equivalent)
  • exec: direct create_subprocess_exec
  • shell: explicit shell execution
  • auto: deterministic fallback policy documented by platform

Also define a unified command-not-found detection strategy and error surface that is stable across OSes.

Acceptance criteria

• Mode is explicit and documented in workflow syntax docs.
• auto behavior is deterministic and tested on Windows + Unix.
• Command-not-found errors map to a consistent Conductor error contract.
• Tests include shell builtins and quoting-sensitive cases in all supported modes.
• Backward compatibility strategy is documented (default mode choice and migration notes).

Notes

Recent improvements addressed real failures by resolving executables more robustly, but this issue tracks the broader long-term platform contract for script-step execution semantics.

[jrob5756]

Closing — the core cross-platform exec/shell behavior was already addressed in PR #10 (exec-first with shell fallback strategy and cross-platform command-not-found detection).