fix(engine): use type-appropriate zero values for optional input defaults

[PolyphonyRequiem]

Problem

Optional workflow inputs without an explicit default: value previously defaulted to Python None. This causes two issues:

1. Templates render "None" — {{ workflow.input.optional_msg }} renders as the literal string "None" instead of empty string
2. | default() doesn't catch None — {{ workflow.input.optional_msg | default("fallback") }} still renders "None" because Jinja's default filter only catches undefined, not None (unless boolean=true is passed)

Reproduction

workflow:
name: test-optionalentry_point: echoinput:
required_id:
type: numberrequired: trueoptional_msg:
type: stringrequired: false# no default: specifiedagents:
- name: echotype: scriptcommand: pwshargs:
- "-Command"
- "Write-Output '{{ workflow.input.optional_msg | default(\"fallback\") }}'; exit 0"routes:
- to: $end

conductor run test.yaml --input required_id=42

Expected: Script outputs fallback (or empty string)
Actual: Script outputs None

Fix

_apply_input_defaults() now uses type-appropriate zero values instead of None for optional inputs with no declared default:

Type	Zero value
string	""
number	0
boolean	false
array	[]
object	{}

Explicit default: values in the schema are still honored. This is a backward-compatible change — templates that checked if workflow.input.X will still work since zero values are falsy.

Changes

• src/conductor/engine/workflow.py: Add _TYPE_ZERO_VALUES class constant, update _apply_input_defaults() to use it
• tests/test_engine/test_workflow.py: Test verifying optional inputs render cleanly (no "None")

Testing

• 75 workflow engine tests pass (including new test)

[Codecov Comments Bot (codecov-commenter)]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (main@dbcf20f). Learn more about missing BASE report.

Additional details and impacted files

@@ Coverage Diff @@## main #123 +/- ##
=======================================
Coverage ? 84.94% =======================================
Files ? 53 Lines ? 7424 Branches ? 0 =======================================
Hits ? 6306 Misses ? 1118 Partials ? 0 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Jason Robert (jrob5756)]

Same comment as before about portability. Other than that, looks good.

[Jason Robert (jrob5756)]

Same as a few other PRs, replace pwsh with sys.executable.

Every other script-type test in this repo uses command=sys.executable with args=["-c", "..."] (see tests/test_engine/test_script_workflow.py:56,87). PowerShell isn't installed on most local dev environments — this test won't even run on a stock macOS/Linux machine without an extra install. The single-quote stdout assertions are also pwsh-specific.

Suggested rewrite (also requires import sys at the top of the file):

command=sys.executable,
args=[
"-c",
(
"print(f'msg={{ workflow.input.optional_msg }}"" count={{ workflow.input.optional_count }}"" def={{ workflow.input.with_default }}')"
),
],

Even better: convert this to a direct unit test of _apply_input_defaults / _zero_value_for_type parametrized over all five types — it would drop the subprocess dependency entirely and exercise the boolean, array, and object branches that the current end-to-end test never touches.

[PolyphonyRequiem]

Both calls (pwsh -> direct unit test, all-five-types coverage) folded into one rewrite in ac928e3. Replaced the e2e test with TestApplyInputDefaults — parametrized over string / number / boolean / array / object directly against _apply_input_defaults, no subprocess, no pwsh. Same class also covers explicit-default-honored, provided-value-passthrough, and required-untouched. Thanks for the nudge to drop the subprocess — much cleaner.

[Jason Robert (jrob5756)]

Coverage gap. This test covers string and number (and the explicit-default path), but not boolean, array, or object. The central claim of the fix is "all five InputDef.type values get a sensible zero," so consider adding assertions for the other three — easiest as a parametrized unit test on _apply_input_defaults directly.

While you're there, a small invariant test on _zero_value_for_type would be worthwhile:

assertengine._zero_value_for_type("array") isnotengine._zero_value_for_type("array")
assertengine._zero_value_for_type("object") isnotengine._zero_value_for_type("object")

This guards against a future "optimization" that caches the mutable instances and reintroduces the classic shared-mutable-default bug.

[PolyphonyRequiem]

Added test_zero_value_for_mutable_type_returns_fresh_instance parametrized over array and object in ac928e3 — exactly the is not invariant you suggested. Locks in the fix from the second commit on this branch so a future cache "optimization" can't quietly reintroduce the shared-mutable-default bug. The boolean/array/object coverage gap is closed by the parametrized _apply_input_defaults test in the same commit.

[Jason Robert (jrob5756)]

All review feedback addressed — tests are notably stronger than originally suggested. CI green. LGTM 🚀