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-optional
  entry_point: echo
  input:
    required_id:
      type: number
      required: true
    optional_msg:
      type: string
      required: false
      # no default: specified
agents:
  - name: echo
    type: script
    command: pwsh
    args:
      - "-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-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.

[jrob5756]

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

[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.

[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:

assert engine._zero_value_for_type("array") is not engine._zero_value_for_type("array")
assert engine._zero_value_for_type("object") is not engine._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.

[jrob5756]

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